5. 安全考虑事项

本文描述的 JWT 访问令牌数据布局与 [OpenID.Core] 定义的 id_token 非常相似. 本配置文件按照 [RFC8725] 的建议要求显式类型标识, 这有助于资源服务器区分 JWT 访问令牌和 OpenID Connect ID Token.

授权服务器应当防止客户端以可能混淆资源服务器的方式影响 "sub" claim 的值. 例如, 如果授权服务器选择把 client_id 用作通过 client credentials grant 签发的访问令牌的 "sub" 值, 则授权服务器应当防止客户端注册任意 client_id 值, 因为恶意客户端可能选择高权限资源所有者的 sub, 从而混淆资源服务器上依赖 "sub" 值的授权逻辑. 更多细节参见 [OAuth2.Security.BestPractices] 第 4.14 节.

为防止跨 JWT 混淆 (cross-JWT confusion), 授权服务器必须使用不同的标识符作为 "aud" claim 值, 以唯一标识同一 issuer 为不同资源签发的访问令牌. 关于跨 JWT 混淆的更多细节, 参见 [RFC8725] 第 2.8 节.

授权服务器在处理可能导致授权授予语义不明确的请求时应格外谨慎. 例如, 如果请求包含多个资源指示符, 授权服务器应确保生成的 JWT 访问令牌中包含的每个 scope 字符串 (如果有) 都能明确关联到 "aud" claim 所列资源中的某一个. 如何识别和缓解这种及其他歧义情况高度依赖具体场景, 因此不属于本配置文件范围.

授权服务器不能依赖分别使用不同密钥签名 OpenID Connect ID Token 和 JWT token 来防范特定密钥泄露的后果. 资源服务器无法知道具体应使用哪一个密钥验证 JWT 访问令牌, 因此必须接受使用 AS metadata 或 OpenID Connect discovery 中发布的任意密钥生成的签名. 因此, 攻击者只要攻破已发布密钥中的任意一个, 就可能生成并签名会被资源服务器接受为有效的 JWT.

---