5. Security Considerations (安全考虑)

此处描述的JWT访问令牌数据布局与[OpenID.Core]定义的id_token非常相似. 此配置文件中要求的显式类型 (Explicit Typing), 符合[RFC8725]中的建议, 有助于资源服务器区分JWT访问令牌和OpenID Connect ID Token.

授权服务器应该防止客户端以可能混淆资源服务器的方式影响 "sub" 声明的值的场景. 例如, 如果授权服务器选择使用client_id作为使用客户端凭证许可 (Client Credentials Grant) 签发的访问令牌的 "sub" 值, 则授权服务器应该防止客户端注册任意的client_id值, 因为这将允许恶意客户端选择高权限资源所有者的sub, 并混淆资源服务器上依赖 "sub" 值的任何授权逻辑. 有关更多详细信息, 请参阅[OAuth2.Security.BestPractices]第4.14节.

为了防止跨JWT混淆 (Cross-JWT Confusion), 授权服务器必须 (MUST) 使用不同的标识符作为 "aud" 声明值, 以唯一标识同一发行者为不同资源签发的访问令牌. 有关跨JWT混淆的更多详细信息, 请参阅[RFC8725]第2.8节.

授权服务器在处理可能导致模糊授权许可的请求时应该特别小心. 例如, 如果请求包含多个资源指示符, 授权服务器应该确保生成的JWT访问令牌中包含的每个作用域字符串 (如果有) 可以明确地与 "aud" 声明中列出的资源之一相关联. 关于如何识别和缓解这种和其他模糊情况的详细信息高度依赖于场景, 因此超出了此配置文件的范围.

授权服务器不能依赖使用不同的密钥来签署OpenID Connect ID Token和JWT令牌作为防止泄露特定密钥的后果的方法. 鉴于资源服务器无法知道应该使用什么密钥来验证特定的JWT访问令牌, 它们必须接受使用AS元数据或OpenID Connect发现中发布的任何密钥执行的签名; 因此, 攻击者只需要破解已发布的密钥中的任何一个, 就能够生成和签署将被资源服务器接受为有效的JWT.