跳到主要内容

2. 客户端注册 (Client Registration)

在启动协议之前, 客户端需要向授权服务器注册. 客户端向授权服务器注册的具体方式超出本规范范围, 但通常涉及最终用户与 HTML 注册表单交互.

客户端注册不要求客户端与授权服务器之间直接交互. 如果授权服务器支持, 注册可以依赖其他方式来建立信任并获取所需的客户端属性, 例如重定向 URI 和客户端类型. 例如, 注册可以使用自签发或第三方签发的断言完成, 也可以由授权服务器通过受信任通道执行客户端发现来完成.

注册客户端时, 客户端开发者应当 (SHALL):

  • 按第 2.1 节所述指定客户端类型;
  • 按第 3.1.2 节所述提供其客户端重定向 URI;
  • 包含授权服务器要求的任何其他信息, 例如应用名称, 网站, 描述, 标志图片, 对法律条款的接受等.

2.1. 客户端类型 (Client Types)​

OAuth 根据客户端能否安全地向授权服务器认证, 即能否保持其客户端凭据的机密性, 定义两种客户端类型:

confidential
能够保持其凭据机密性的客户端, 例如部署在安全服务器上且对客户端凭据访问受限的客户端; 或者能够使用其他方式进行安全客户端认证的客户端.

public
无法保持其凭据机密性的客户端, 例如在资源所有者所用设备上执行的客户端, 包括已安装的原生应用或基于 Web 浏览器的应用; 并且也无法通过任何其他方式进行安全客户端认证.

客户端类型的指定基于授权服务器对安全认证的定义, 以及其对客户端凭据可接受暴露程度的判断. 授权服务器不应该 (SHOULD NOT) 对客户端类型作出假设.

一个客户端可以实现为一组分布式组件, 每个组件具有不同的客户端类型和安全上下文, 例如同时包含 confidential 服务器端组件和 public 浏览器端组件的分布式客户端. 如果授权服务器不支持此类客户端, 或未提供其注册指导, 客户端应该 (SHOULD) 将每个组件注册为单独的客户端.

本规范围绕以下客户端配置文件设计:

web application
Web 应用是运行在 Web 服务器上的 confidential 客户端. 资源所有者通过其设备上的用户代理渲染的 HTML 用户界面访问客户端. 客户端凭据以及发放给客户端的任何访问令牌都存储在 Web 服务器上, 不会暴露给资源所有者, 也不能由资源所有者访问.

user-agent-based application
基于用户代理的应用是 public 客户端, 其客户端代码从 Web 服务器下载, 并在资源所有者所用设备上的用户代理 (例如 Web 浏览器) 内执行. 协议数据和凭据很容易被资源所有者访问, 且通常对其可见. 由于此类应用驻留在用户代理内, 在请求授权时可以无缝使用用户代理能力.

native application
原生应用是安装并运行在资源所有者所用设备上的 public 客户端. 协议数据和凭据可由资源所有者访问. 假定应用中包含的任何客户端认证凭据都可以被提取. 另一方面, 动态签发的凭据, 例如访问令牌或刷新令牌, 可以获得可接受级别的保护. 至少, 这些凭据会受到保护, 免于被应用可能交互的恶意服务器获取. 在某些平台上, 这些凭据也可能受到保护, 免于被同一设备上的其他应用获取.

2.2. 客户端标识符 (Client Identifier)​

授权服务器向已注册客户端发放客户端标识符 (Client Identifier), 这是一个表示客户端所提供注册信息的唯一字符串. 客户端标识符不是秘密; 它会暴露给资源所有者, 且不得 (MUST NOT) 单独用于客户端认证. 客户端标识符在授权服务器内唯一.

本规范未定义客户端标识符字符串的大小. 客户端应避免对标识符大小作出假设. 授权服务器应该 (SHOULD) 文档化其发放的任何标识符的大小.

2.3. 客户端认证 (Client Authentication)​

如果客户端类型为 confidential, 客户端与授权服务器会建立一种适合授权服务器安全要求的客户端认证方法. 授权服务器可以 (MAY) 接受任何满足其安全要求的客户端认证形式.

confidential 客户端通常会被发放或建立一组客户端凭据, 用于向授权服务器认证, 例如密码或公钥/私钥对.

授权服务器可以 (MAY) 与 public 客户端建立客户端认证方法. 但是, 授权服务器不得 (MUST NOT) 依赖 public 客户端认证来识别客户端.

客户端在每个请求中不得 (MUST NOT) 使用超过一种认证方法.

2.3.1. 客户端密码 (Client Password)​

持有客户端密码的客户端可以 (MAY) 使用 [RFC2617] 定义的 HTTP Basic 认证方案向授权服务器认证. 客户端标识符按附录 B 的 "application/x-www-form-urlencoded" 编码算法进行编码, 编码后的值用作用户名; 客户端密码使用同一算法编码并用作密码. 授权服务器必须 (MUST) 支持 HTTP Basic 认证方案, 以认证已被发放客户端密码的客户端.

例如 (额外换行仅为显示目的):

Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

或者, 授权服务器可以 (MAY) 支持使用以下参数将客户端凭据包含在请求主体中:

client_id
必需 (REQUIRED). 第 2.2 节所述注册过程中发放给客户端的客户端标识符.

client_secret
必需 (REQUIRED). 客户端密钥. 如果客户端密钥为空字符串, 客户端可以 (MAY) 省略该参数.

使用这两个参数在请求主体中包含客户端凭据不推荐 (NOT RECOMMENDED), 并且应该 (SHOULD) 限于无法直接使用 HTTP Basic 认证方案 (或其他基于密码的 HTTP 认证方案) 的客户端. 这些参数只能在请求主体中传输, 不得 (MUST NOT) 包含在请求 URI 中.

例如, 使用主体参数刷新访问令牌 (第 6 节) 的请求如下 (额外换行仅为显示目的):

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

使用密码认证发送请求时, 授权服务器必须 (MUST) 要求使用第 1.6 节所述的 TLS.

由于这种客户端认证方法涉及密码, 授权服务器必须 (MUST) 保护任何使用该方法的端点免受暴力破解攻击.

2.3.2. 其他认证方法 (Other Authentication Methods)​

授权服务器可以 (MAY) 支持任何符合其安全要求的合适 HTTP 认证方案. 使用其他认证方法时, 授权服务器必须 (MUST) 定义客户端标识符 (注册记录) 与认证方案之间的映射.

2.4. 未注册客户端 (Unregistered Clients)​

本规范不排除使用未注册客户端. 但是, 使用此类客户端超出本规范范围, 并且需要额外的安全分析以及对互操作性影响的审查.

最后于 更新