3. Mutual-TLS Client Certificate-Bound Access Tokens (Mutual-TLS 客户端证书绑定访问令牌)

3. Mutual-TLS Client Certificate-Bound Access Tokens (Mutual-TLS 客户端证书绑定访问令牌)

当客户端在到 token endpoint (令牌端点) 的连接上使用 mutual TLS 时, 授权服务器能够将颁发的 access token 绑定到客户端证书. 该绑定通过以使受保护资源可访问的方式将证书与令牌关联来完成, 例如按第 3.1 节所述语法直接将证书哈希嵌入所颁发的 access token, 或按第 3.2 节通过 token introspection (令牌内省). 以该方式将 access token 绑定到客户端证书的好处是, 将该绑定与客户端对授权服务器的认证解耦, 从而使受保护资源访问期间的 mutual TLS 可纯粹作为 proof-of-possession (持有证明) 机制. 经授权服务器与受保护资源约定, 还可采用其他将证书与 access token 关联的方法, 但超出本规范范围.

为使 resource server (资源服务器) 使用证书绑定的 access token, 其必须事先知晓对某些或全部资源访问将使用 mutual TLS. 特别地, access token 本身不能作为是否请求 mutual TLS 的决策输入, 因为 (从 TLS 角度) 它是 "Application Data (应用数据)", 仅在 TLS 握手完成后交换, 而初始 CertificateRequest 发生在握手期间, 在应用数据可用之前. 尽管 TLS 客户端后续可能还有机会出示证书, 例如通过 TLS 1.2 重协商 [RFC5246] 或 TLS 1.3 post-handshake authentication (握手后认证) [RFC8446], 本文档不对其使用作出规定. 预期常见情形是, 使用 mutual TLS 的资源服务器会对其托管的所有资源要求 mutual TLS, 或在不同 hostname 与 port 组合上分别提供 mutual-TLS 保护与常规资源, 尽管其他工作流也可能存在. 资源服务器策略如何与授权服务器 (AS) 同步不在本文档范围内.

在 mutual-TLS 保护的资源访问流程范围内, 客户端按 [RFC6750] 所述发出受保护资源请求, 但这些请求必须通过双向认证的 TLS 连接发出, 且使用与在 token endpoint 进行 mutual TLS 时相同的证书.

受保护资源必须从其 TLS 实现层获取用于 mutual TLS 的客户端证书, 并必须验证该证书与 access token 关联的证书匹配. 若不匹配, 必须按照 [RFC6750] 以 HTTP 401 状态码和 invalid_token 错误码拒绝资源访问尝试.

传达 mutual-TLS 客户端证书绑定 access token 的服务器与客户端能力的元数据分别在第 3.3 节与第 3.4 节定义.