跳到主要内容

1. 引言

为了让 OAuth 2.0 [RFC6749] 客户端能够使用 OAuth 2.0 授权服务器, 客户端需要特定信息来与服务器交互, 包括在该服务器上使用的 OAuth 2.0 客户端标识符. 本规范描述 OAuth 2.0 客户端如何动态注册到授权服务器以获取这些信息.

作为注册过程的一部分, 本规范还定义一种机制, 使客户端能够向授权服务器提供一组元数据, 例如一组有效的重定向 URI. 这些元数据可以以自声明方式传递, 也可以作为称为软件声明 (software statement) 的一组元数据传递, 后者经过数字签名或使用消息认证码 (Message Authentication Code, MAC) 保护; 对于软件声明, 发行方为有关客户端的数据有效性背书.

传统上, 客户端向授权服务器注册是手动完成的. 本规范定义的机制既可用于客户端向授权服务器动态注册自身, 也可用于客户端开发者以编程方式向授权服务器注册客户端. 以前, 多个使用 OAuth 2.0 的应用已经开发了完成此类注册的机制. 本规范泛化了 "OpenID Connect Dynamic Client Registration 1.0" [OpenID.Registration] 定义并由 "User Managed Access (UMA) Profile of OAuth 2.0" [UMA-Core] 使用的注册机制, 以同时兼容二者, 并适用于更广泛的 OAuth 2.0 使用场景.

1.1. 符号约定​

本文档中的关键词 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 和 'OPTIONAL' 应按 [RFC2119] 中的描述解释.

除非另有说明, 所有协议参数名和值都区分大小写.

1.2. 术语​

本规范使用 OAuth 2.0 [RFC6749] 定义的术语 "access token", "authorization code", "authorization endpoint", "authorization grant", "authorization server", "client", "client identifier", "client secret", "grant type", "protected resource", "redirection URI", "refresh token", "resource owner", "resource server", "response type", 和 "token endpoint", 并使用 JSON Web Token (JWT) [RFC7519] 定义的术语 "Claim".

本规范定义以下术语:

客户端软件 (Client Software) 实现 OAuth 2.0 客户端的软件.

客户端实例 (Client Instance) 一份客户端软件的已部署实例.

客户端开发者 (Client Developer) 构建客户端软件包并准备分发它的个人或组织. 在构建客户端时, 开发者通常并不知道部署服务提供方组织会是谁. 当客户端开发者在编译时无法预测软件的某些方面, 例如部署 URL 时, 需要使用动态注册. 例如, 当软件 API 发布方和部署组织不是同一方时, 就可能出现这种情况.

客户端注册端点 (Client Registration Endpoint) OAuth 2.0 端点, 客户端可通过该端点注册到授权服务器. 获取此端点 URL 的方式不在本规范范围内.

初始访问令牌 (Initial Access Token) 授权服务器可选地向开发者或客户端签发的 OAuth 2.0 访问令牌, 用于授权调用客户端注册端点. 此令牌的类型和格式很可能是服务特定的, 不在本规范范围内. 授权服务器签发此令牌的方式以及注册端点验证此令牌的方式不在本规范范围内. 当授权服务器限制可注册客户端的各方时, 需要使用初始访问令牌.

部署组织 (Deployment Organization) 一个管理安全域, 软件 API (服务) 在该域下部署并由 OAuth 2.0 框架保护. 在某些 OAuth 场景中, 部署组织和软件 API 发布方相同. 在这些情况下, 部署组织通常与客户端软件开发者有密切关系. 在许多其他情况下, 服务定义方可能是独立的第三方发布方或标准组织. 当基于某个 API 的已发布规范工作时, 客户端软件开发者无法预先与可能部署该软件 API (服务) 的多个部署组织建立关系.

软件 API 部署 (Software API Deployment) 在特定部署组织域中, 由 OAuth 2.0 保护的软件 API (受保护资源) 的已部署实例. 对于任何特定软件 API, 可以有一个或多个部署. 软件 API 部署通常有一个关联的 OAuth 2.0 授权服务器以及客户端注册端点. 获取端点的方式不在本规范范围内.

软件 API 发布方 (Software API Publisher) 定义某个可通过 Web 访问的 API 的组织, 该 API 可部署在一个或多个部署环境中. 发布方可以是任何标准机构, 商业组织, 公共组织, 私有组织或开源组织, 负责发布和分发可通过 OAuth 2.0 保护的软件和 API 规范. 在某些情况下, 软件 API 发布方和客户端开发者可能是同一组织. 在发布可通过 Web 访问的 API 时, 软件发布方通常与部署组织没有预先关系.

软件声明 (Software Statement) 一个经过数字签名或 MAC 保护的 JSON Web Token (JWT) [RFC7519], 用于断言有关客户端软件的元数据值. 在某些情况下, 软件声明将由客户端开发者直接签发. 在其他情况下, 软件声明将由第三方组织签发, 供客户端开发者使用. 在这两种情况下, 授权服务器与软件声明发行方之间的信任关系旨在作为评估是否接受注册请求的输入. 软件声明可以作为客户端注册请求的一部分提交给授权服务器.

1.3. 协议流程​

    +--------(A)- Initial Access Token (OPTIONAL)
    |
    |   +----(B)- Software Statement (OPTIONAL)
    |   |
    v   v
+-----------+                                      +---------------+
|           |--(C)- Client Registration Request -->|    Client     |
| Client or |                                      | Registration  |
| Developer |<-(D)- Client Information Response ---|   Endpoint    |
|           |        or Client Error Response      +---------------+
+-----------+

图 1: 抽象动态客户端注册流程

图 1 所示的抽象 OAuth 2.0 客户端动态注册流程描述客户端或开发者与本规范定义的端点之间的交互. 该图未展示错误条件. 此流程包括以下步骤:

(A) 可选地, 向客户端或开发者签发一个初始访问令牌, 以授予其访问客户端注册端点的权限. 初始访问令牌签发给客户端或开发者的方式不在本规范范围内.

(B) 可选地, 向客户端或开发者签发一个软件声明, 用于客户端注册端点. 软件声明签发给客户端或开发者的方式不在本规范范围内.

(C) 客户端或开发者使用客户端期望的注册元数据调用客户端注册端点, 如果授权服务器要求, 可选地包括来自 (A) 的初始访问令牌.

(D) 授权服务器注册客户端并返回:

  *  客户端的已注册元数据,

  *  在服务器上唯一的客户端标识符, 以及

  *  一组客户端凭据, 例如客户端密钥, 如果适用于此客户端.

不同配置和用法的示例包含在附录 A 中.

最后于 更新