关于Token V1和V2在Postman中的不一致性及配置疑问

关于requestedAccessTokenVersion参数的设计意图与异常返回v1 token的原因 #

requestedAccessTokenVersion的核心设计目标是明确指定客户端期望获取的access token版本，当设置为"2"时，服务端应优先返回v2版本的access token。出现返回v1 token的情况，通常由以下场景导致：

• 目标API端点不兼容v2 token：部分旧版API端点仅支持v1 token，为保证兼容性，服务端会自动降级返回v1 token，而非直接报错。
• 应用配置限制：若你的应用在身份认证服务中被配置为仅允许生成v1 token（如权限范围、token版本白名单设置），即使请求指定v2版本，也会被服务端拦截并返回v1 token。
• 请求上下文冲突：如果请求中携带了与v1 token绑定的参数（如旧refresh token、v1格式授权码），服务端会沿用旧版本逻辑返回v1 token。

关于v1端点仅返回ID token及强制版本统一的解决方案 #

v1 token端点的设计逻辑通常仅聚焦于生成v1格式的ID token，部分场景下不支持生成access token，这是v1与v2端点的职责划分差异导致的——v2端点的核心改进之一就是统一身份凭证体系，支持同版本的ID token与access token生成。

要强制两者版本统一，可参考以下方案：

• 统一使用v2 token端点：所有token请求切换至v2端点，通过requestedAccessTokenVersion指定目标版本，服务端会返回同版本的ID token与access token（需确保应用配置支持对应版本）。
• 调整应用权限配置：在身份认证服务的应用设置中，开启"强制token版本统一"选项（若提供），或关闭v1 token生成权限，确保所有请求走v2逻辑。
• 客户端侧校验：添加token版本校验逻辑，若返回的ID token与access token版本不一致，直接重试请求或抛出错误，避免版本不兼容问题。

内容的提问来源于stack exchange，提问作者Marco Araya