4. 安全考量 (Security Considerations)

客户端必须 (MUST) 严格按照 Section 2.4 中的描述验证 iss 参数, 且禁止 (MUST NOT) 允许多个授权服务器使用同一个颁发者标识符. 尤其是在客户端可以手动配置授权服务器详细信息时, 客户端必须 (MUST) 确保接受的 iss 值对每个授权服务器都是唯一的.

iss 参数使客户端能够判断某个授权服务器是否"预期"在 OAuth 流程中与某个令牌端点 (token endpoint) 以及可能的其他端点一起使用, 例如 userinfo 端点 [OIDC.Core]. 使用 OAuth 元数据时, iss 参数标识颁发者, 因而也标识指向其他端点的相应 OAuth 元数据文档. 不使用 OAuth 元数据时, 客户端可以为每个已配置的授权服务器使用静态配置的预期 iss 值.

授权响应中包含的颁发者标识符并未通过密码学方式防篡改. 一般而言, 可以使用 JWT 等机制 (如 [JARM] 所规定) 来保护授权响应的完整性. 但是, 在混淆攻击中, 客户端通常从未被攻陷的授权服务器接收授权响应. 如果攻击者能在客户端收到授权响应之前篡改它, 攻击者也会直接获得授权码. 攻击者不需要执行混淆攻击就能窃取授权码. 因此, 为抵御混淆攻击, 并不需要对授权响应提供完整性保护.

也存在其他抵御混淆攻击的对策. 如果授权响应已经通过其他方式包含授权服务器的颁发者标识符, 且该标识符按照 Section 2.4 所述方式进行了检查, 则不需要使用和验证 iss 参数, 可以 (MAY) 省略. 例如, 使用从授权端点返回 ID Token 的 OpenID Connect 响应类型 (如 response_type=code id_token) 或 [JARM] 时就是这种情况. 但是, 如果客户端收到的授权响应包含多个颁发者标识符, 且这些标识符不匹配, 客户端必须 (MUST) 拒绝该响应. 替代对策的细节不在本规范范围内.

混淆攻击只与会和多个授权服务器交互的客户端相关. 但是, 目前只与一个授权服务器交互的客户端将来可能会增加对第二个授权服务器的支持. 一旦支持多个授权服务器, 它们就会变得易受混淆攻击影响, 并需要应用相应对策.