1. Introduction (简介)

OAuth 2.0 Authorization Framework (授权框架) [RFC6749] 使第三方 client application (客户端应用) 能够获得对 protected resource (受保护资源) 的委托访问. 在图 1 所示的典型抽象 OAuth 流程中, client (客户端) 从称为 authorization server (授权服务器) 的实体获取 access token (访问令牌), 然后在访问受保护资源 (例如 HTTPS API) 时使用该令牌.

  +--------+                                 +---------------+
  |        |                                 |               |
  |        |<--(A)-- Get an access token --->| Authorization |
  |        |                                 |     Server    |
  |        |                                 |               |
  |        |                                 +---------------+
  |        |                                         ^
  |        |                                         |
  |        |
  |        |                               (C)       |
  | Client |                           Validate the
  |        |                           access token  |
  |        |
  |        |                                         |
  |        |                                         v
  |        |                                 +---------------+
  |        |                                 |      (C)      |
  |        |                                 |               |
  |        |<--(B)-- Use the access token -->|   Protected   |
  |        |                                 |    Resource   |
  |        |                                 |               |
  +--------+                                 +---------------+

              Figure 1: Abstract OAuth 2.0 Protocol Flow

图 1 所示流程包含以下步骤:

(A) 客户端向授权服务器发起 HTTPS POST 请求, 并出示代表 authorization grant (授权许可) 的凭据. 对于某些类型的客户端 (已获发或以其他方式建立了一组 client credentials (客户端凭据) 者), 该请求必须经过认证. 在响应中, 授权服务器向客户端颁发 access token.

(B) 客户端在请求访问受保护资源时包含 access token.

在上述抽象流程之上, 本文档针对 OAuth 2.0 规范化了利用基于 client certificate (客户端证书) 的 mutual TLS (双向 TLS) 的增强安全选项. 第 2 节提供对步骤 (A) 中请求进行认证的选项. 步骤 (C) 通过在第 3.1 节与第 3.2 节中分别表达的语义, 支持将令牌绑定到客户端证书, 以用于本地与远程处理. 这确保如第 3 节所述, 步骤 (B) 中的受保护资源访问仅可能由合法客户端使用 certificate-bound token (证书绑定令牌) 并持有与证书对应的私钥来完成.

OAuth 2.0 定义了基于 shared secret (共享密钥) 的客户端认证方式, 但也允许在与授权服务器直接交互时定义并使用额外的客户端认证机制. 本文档描述一种利用 mutual-TLS 基于证书的客户端认证的附加机制, 其安全特性优于共享密钥. 虽然 [RFC6749] 记载了对 token endpoint (令牌端点) 请求的客户端认证, 但 OAuth 2.0 的扩展 (例如 Introspection (内省) [RFC7662], Revocation (撤销) [RFC7009], 以及 [OpenID.CIBA] 中的 Backchannel Authentication Endpoint (背通道认证端点)) 定义了同样使用客户端认证的端点, 本文定义的 mutual-TLS 方法也适用于这些端点.

Mutual-TLS certificate-bound access token (mutual-TLS 证书绑定访问令牌) 确保只有持有与证书对应私钥的一方才能使用该令牌访问关联资源. 此类约束有时称为 key confirmation (密钥确认), proof-of-possession (持有证明) 或 holder-of-key, 不同于 [RFC6750] 中描述的 bearer token (持有者令牌) 情形, 在后者中任何持有 access token 的一方都可使用该令牌访问关联资源. 将 access token 绑定到客户端证书可防止被盗 access token 的使用或未经授权方重放 access token.

Mutual-TLS 证书绑定 access token 与 mutual-TLS 客户端认证是不同机制, 互为补充但不必一起部署或使用.

本文档引入额外的 client metadata (客户端元数据) 参数以支持证书绑定 access token 与 mutual-TLS 客户端认证. 授权服务器可通过 Dynamic Client Registration Protocol (动态客户端注册协议) [RFC7591] 获取客户端元数据, 该协议定义了向授权服务器动态注册 OAuth 2.0 客户端元数据的机制. 此外, [RFC7591] 定义的元数据及其已注册扩展隐含了适用于客户端的一般数据模型, 对授权服务器实现很有用, 即便未使用动态客户端注册协议. 此类实现通常会有某种用于管理客户端配置的用户界面.

1. Introduction (简介)​

1. Introduction (简介)