1. 简介 (Introduction)
安全令牌 (security token) 是一组信息, 用于在异构环境中或跨安全域共享身份与安全信息. 安全令牌的示例包括 JSON Web Token (JWT) [JWT] 和 Security Assertion Markup Language (SAML) 2.0 断言 [OASIS.saml-core-2.0-os]. 安全令牌通常会被签名以提供完整性, 有时也会被加密以提供机密性. 安全令牌有时也称为断言 (assertion), 例如 [RFC7521] 中的用法.
安全令牌服务 (Security Token Service, STS) 是一种能够验证提交给它的安全令牌, 并据此签发新安全令牌的服务. 这使客户端可以在异构环境中或跨安全域为资源取得合适的访问凭据. Web Service 客户端曾使用 WS-Trust [WS-Trust] 作为与 STS 交互以进行令牌交换的协议. WS-Trust 使用 XML 和 SOAP, 而现代 Web 开发的趋势则转向 RESTful (Representational State Transfer) 模式和 JSON. OAuth 2.0 授权框架 [RFC6749] 与 OAuth 2.0 Bearer Token [RFC6750] 已成为授权第三方应用访问 HTTP 和 RESTful 资源的常用标准. 传统 OAuth 2.0 交互会把某种资源所有者授权表示交换为访问令牌, 这种模式在实践中非常有用. 但是, 若要完整承载一个安全令牌交换框架, 其输入和输出形式本身仍显得过于受限.
本规范定义了一个扩展 OAuth 2.0 的协议, 使客户端能够从充当 STS 的授权服务器请求并获取安全令牌. 与 OAuth 2.0 类似, 本规范关注客户端开发者的简单性, 只要求 HTTP 客户端和 JSON 解析器, 而这些能力在现代开发环境中几乎普遍可用. 本规范定义的 STS 协议本身并不是 RESTful 的 (STS 并不特别适合 REST 方法), 但它确实使用了熟悉 RESTful 系统的开发者应当熟悉的通信模式和数据格式.
本规范为令牌交换请求定义了一种新的授权类型 (grant type), 并定义了这类请求发送到令牌端点时使用的特定参数. 令牌交换响应是来自令牌端点的普通 OAuth 2.0 响应, 但额外定义了少量参数, 用于向客户端提供信息.
在令牌交换交互的上下文中, 发起令牌交换请求的实体被视为客户端. 不过, 这并不限制此配置文件只能用于传统 OAuth 客户端. 例如, OAuth 资源服务器可以在令牌交换期间承担客户端角色, 将它在受保护资源请求中收到的访问令牌交换为适合放入后端服务调用的新令牌. 这个新令牌可以是作用域更窄、面向下游服务的访问令牌, 也可以是完全不同类型的令牌.
本规范的范围限于定义一种基于 OAuth 2.0 的 STS 风格令牌交换基础请求-响应协议. 虽然本规范定义了少量新的 JWT 声明 (claims), 用于表达委派语义, 但令牌本身的具体语法、语义和安全特性 (包括提交给授权服务器的令牌和客户端获得的令牌) 明确不在本规范范围内, 本规范也不对实现部署时采用的信任模型提出要求. 其他配置文件可以围绕参与方和信任关系的具体性质提出更详细的要求, 例如令牌是否需要签名和/或加密, 或是否要求、签发持有证明 (proof-of-possession) 风格的令牌. 不过, 这些细节通常是针对单个部署的具体需求作出的策略决定, 并会据此配置或实现.
获得的安全令牌可以在多种上下文中使用, 其具体细节同样不在本规范范围内.
1.1. 委派与模拟语义 (Delegation vs. Impersonation Semantics)
STS 的一个常见用例 (上一节也有所提及) 是允许资源服务器 A 代表发起请求的用户 B 调用后端服务 C. 根据本地站点策略和授权基础设施, A 可能需要使用自己的凭据访问 C, 并附带某种形式的注记来说明 A 正代表 B 行事 ("委派"), 也可能需要让 A 获得访问 C 的受限访问凭据, 但该凭据仍将 B 标识为被授权实体 ("模拟"). 委派和模拟在涉及多个参与方的其他场景中也可能是有用概念.
当主体 A 模拟主体 B 时, A 会在某个已定义的权限上下文中获得 B 拥有的全部权限, 并且在该上下文中与 B 不可区分. 因此, 当主体 A 模拟主体 B 时, 对任何接收这类令牌的实体而言, 它实际面对的是 B. 身份系统中的某些成员可能知道模拟正在发生, 但这不是要求. 就所有实际目的而言, 当 A 模拟 B 时, 在令牌授权的权限上下文中 A 就是 B. A 模拟 B 的能力可以在范围或时间上受到限制, 甚至可以附加一次性使用限制, 这些限制既可以通过令牌内容表达, 也可以通过带外机制实现.
委派语义不同于模拟语义, 尽管二者密切相关. 在委派语义下, 主体 A 仍拥有独立于 B 的自身身份, 并且各方明确理解: 虽然 B 可能已经把部分权限委派给 A, 但所执行的动作是由代表 B 的 A 发起的. 从某种意义上说, A 是 B 的代理.
委派和模拟并不覆盖所有情形. 例如, 当主体直接代表自身行事时, 既不存在委派, 也不存在模拟. 但是, 它们是令牌交换中较常见的语义, 因此本规范对其作了更直接的处理.
委派语义通常通过在令牌中同时包含令牌的主要主体以及该主体向其委派部分权限的参与者信息来表达. 这种令牌有时称为复合令牌 (composite token), 因为它由多个主体的信息组成. 通常在请求中, subject_token 表示代表其请求令牌的一方的身份, 而 actor_token 表示已签发令牌的访问权限要委派给的一方的身份. 授权服务器签发的复合令牌会包含双方的信息. 是否以及何时签发复合令牌由授权服务器以及适用的策略和配置决定.
如何表示复合令牌, 甚至是否签发这种令牌, 都取决于实现细节和令牌类型. 非 JWT 复合令牌的表示方式不在本规范范围内. 不过, actor_token 请求参数确实提供了一种传递期望参与者信息的方法, JWT 的 act 声明也可以表示一条委派链.
1.2. 要求表示法和约定 (Requirements Notation and Conventions)
本文档中的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 在且仅在以这里所示的全大写形式出现时, 应按 BCP 14 [RFC2119] [RFC8174] 中的说明解释.
1.3. 术语 (Terminology)
本规范使用 OAuth 2.0 [RFC6749] 定义的术语 "access token type", "authorization server", "client", "client identifier", "resource server", "token endpoint", "token request" 和 "token response", 以及 JSON Web Token (JWT) [JWT] 定义的术语 "Base64url Encoding", "Claim" 和 "JWT Claims Set".