RFC 8693 OAuth 2.0 令牌交换 2020 年 1 月
Jones 等 标准轨道 [页]
流：
互联网工程任务组（IETF）
RFC：
8693
类别：
标准轨道
发布时间：
ISSN：
2070-1721
作者：
M. Jones
Microsoft
A. Nadalin
Microsoft
B. Campbell, 编
Ping Identity
J. Bradley
Yubico
C. Mortimore
Visa

RFC 8693

OAuth 2.0 令牌交换

摘要

本规范定义了一种用于基于 HTTP 和 JSON 的 安全令牌服务（STS）的协议，方式是定义如何从 OAuth 2.0 授权服务器请求和获取安全令牌， 包括采用身份模拟和委派的安全令牌。

本备忘录状态

这是一份 Internet 标准轨道文档。

本文档是互联网工程任务组 （IETF）的成果。它代表了 IETF 社区的共识。它已 接受公开评审，并已由 Internet 工程指导组（IESG）批准发布。有关 Internet 标准的更多信息可参见 RFC 7841 第 2 节。

有关本文档当前状态、任何勘误以及如何提供反馈的信息， 可在 https://www.rfc-editor.org/info/rfc8693 获得。

▲

目录

1. 引言

安全令牌是一组信息，用于促进在异构环境中或跨 安全域共享身份和安全信息。安全令牌的示例包括 JSON Web Tokens (JWTs) [JWT] 和 Security Assertion Markup Language (SAML) 2.0 断言 [OASIS.saml-core-2.0-os]。 安全令牌通常会被签名以实现完整性，有时也会加密以 实现机密性。安全令牌有时也被描述为 断言，例如在 [RFC7521] 中。

安全令牌服务（STS）是一种能够验证提供给它的 安全令牌，并作为响应颁发新的安全令牌的服务； 这使客户端能够在异构环境中或跨安全 域为资源获取适当的 访问凭据。 Web Service 客户端曾使用 WS-Trust [WS-Trust] 作为与 STS 交互以进行令牌交换的协议。 虽然 WS-Trust 使用 XML 和 SOAP，但现代 Web 开发的趋势 已经转向 RESTful（Representational State Transfer）模式和 JSON。 OAuth 2.0 Authorization Framework [RFC6749] 和 OAuth 2.0 Bearer Tokens [RFC6750] 已成为授权第三方 应用访问 HTTP 和 RESTful 资源的流行标准。 传统的 OAuth 2.0 交互涉及将资源所有者授权的某种 表示交换为访问令牌， 这种模式在实践中已被证明极其有用。然而， 就目前而言，其输入和输出在某种程度上过于受限， 无法完全适应安全令牌交换框架。

本规范定义了一种扩展 OAuth 2.0 的协议，使 客户端能够从扮演 STS 角色的授权服务器请求和获取安全令牌。 与 OAuth 2.0 类似，本规范侧重于客户端开发者的简单性，并且 只要求 HTTP 客户端和 JSON 解析器，而这在现代开发环境中几乎普遍可用。 本规范定义的 STS 协议本身并不是 RESTful 的（STS 并不特别适合 REST 方法），但确实利用了那些应当为习惯于使用 RESTful 系统的开发者所 熟悉的通信模式和数据格式。

本规范定义了用于令牌交换请求的新授权类型，以及向 令牌端点提出此类请求时相关的特定参数。 令牌交换响应是来自令牌端点的普通 OAuth 2.0 响应， 并带有本文定义的少量附加参数，以向客户端提供信息。

发出交换令牌请求的实体，在令牌交换交互的上下文中被视为客户端。 但是，这并不限制 该配置文件只能用于传统 OAuth 客户端。例如，OAuth 资源服务器 可能在令牌交换期间承担客户端的角色，以便将其在受保护资源请求中收到的 访问令牌 交换为适合包含在对后端 服务调用中的新令牌。新令牌可能是一个 针对下游服务范围更窄的访问令牌，或者也可能是一种完全不同类型的 令牌。

本规范的范围限于定义一个 使用 OAuth 2.0 的 STS 风格令牌交换的基本请求-响应协议。 尽管定义了一些新的 JWT 声明，使委派语义能够被表达， 但令牌本身（包括提供给授权服务器的令牌以及客户端获得的令牌）的 具体语法、语义和安全特性 明确不在范围内，并且不对实现可能部署在其中的信任模型 提出任何要求。其他配置文件可以提供 关于各方具体性质和所涉及信任的更详细要求， 例如是否需要对令牌进行签名和/或加密，或者是否会要求或颁发 proof-of-possession 风格 的令牌。然而，这些细节 通常是根据各个部署的具体需要作出的策略决策， 并会相应地进行配置或实现。

获得的安全令牌可以在多种上下文中使用， 这些上下文的具体细节也超出了本规范的范围。

1.1. 委派与 身份模拟语义

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 的代理。

委派和身份模拟并不涵盖所有情形。 例如，当主体直接代表自己行事时， 既不存在委派也不存在身份模拟。不过， 它们是令牌交换中较为常见的语义，因此 在本规范中得到了更直接的处理。

委派语义通常通过在令牌中同时包含关于该令牌主要主体的信息，以及关于该主体已向其委派部分 权利的参与者的信息来表达。 这样的令牌有时称为复合令牌，因为它由关于多个主体的信息组成。 通常，在请求中，subject_token 表示正在代表其请求令牌的一方的身份， 而 actor_token 表示 正在向其委派已颁发令牌访问权的一方的身份。 由授权服务器颁发的复合令牌将包含关于双方的信息。 是否以及何时颁发复合令牌，由授权服务器以及 适用的策略和配置自行决定。

表示复合令牌的具体方式，甚至是否 会颁发此类令牌，取决于实现的细节 和令牌的种类。非 JWT 的复合令牌表示 不在本规范范围内。不过，actor_token 请求 参数确实提供了 一种提供所期望参与者相关信息的手段，而 JWT act 声明可以提供 委派链的表示。

1.2. 要求表示法 和约定

本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、 "MAY" 和 "OPTIONAL" 按 BCP 14 [RFC2119] [RFC8174] 中所述解释，当且仅当它们像这里所示以全大写形式出现时。

1.3. 术语

本规范使用 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"。

2. 令牌交换请求和响应

2.1. 请求

客户端通过使用 第 4.5 节 of [RFC6749] 中定义的扩展授权类型机制，向授权服务器的令牌端点发出令牌请求， 以请求安全令牌。

对授权服务器的客户端认证使用 OAuth 2.0 提供的常规 机制完成。 第 2.3.1 节 of [RFC6749] 定义了基于密码的客户端认证； 但是，客户端认证是可扩展的，也可能使用其他机制。 例如，[RFC7523] 定义了使用 bearer JSON Web Tokens (JWTs) [JWT] 的客户端认证。 支持哪些客户端认证方法，以及是否允许 未认证或未识别的客户端，都是部署决策， 由授权服务器自行决定。 请注意，省略客户端认证会使 持有受损令牌的任何人都能通过 STS 将该受损令牌 利用为其他令牌。因此，客户端 认证允许 STS 进行额外的授权检查，以确定哪些 实体被允许模拟其他实体或从其他 实体接收委派。

客户端使用 HTTP POST 方法，带着扩展授权类型向令牌端点 发出令牌交换请求。以下参数包含在 HTTP 请求实体正文中， 使用 application/x-www-form-urlencoded 格式，并采用 UTF-8 字符编码，如 附录 B of [RFC6749] 所述。

grant_type
REQUIRED。值 urn:ietf:params:oauth:grant-type:token-exchange 表示正在执行令牌交换。
resource
OPTIONAL。 一个 URI，表示客户端打算在其中使用所请求安全令牌的目标服务或资源。 这使授权服务器能够根据目标适当地应用策略， 例如确定要颁发的令牌类型和内容，或者令牌是否以及如何 加密。 在许多情况下，客户端并不知道其交互系统的逻辑组织， 只知道其打算使用该令牌的服务 URI。 resource 参数允许客户端向授权 服务器指明其打算在何处使用已颁发令牌，方法是在 令牌交换请求中提供位置，通常作为 https URL，且其形式与访问该资源时使用的形式相同。 授权服务器通常具有从资源 URI 值映射到 适当策略的能力。resource 参数的值 MUST 是 一个绝对 URI，如 第 4.3 节 of [RFC3986] 所规定； 它 MAY 包含查询组件，且 MUST NOT 包含片段组件。 可以使用多个 resource 参数来指明 已颁发令牌打算用于列出的多个资源。 关于 resource 参数的更多背景和用法，参见 [OAUTH-RESOURCE]。
audience
OPTIONAL。目标服务的逻辑名称，客户端打算 在其中使用所请求的安全令牌。它的用途类似于 resource 参数，但客户端 为目标服务提供的是逻辑名称。对该 名称的解释要求其值是客户端和 授权服务器双方都能理解的内容。OAuth 客户端标识符、SAML 实体 标识符 [OASIS.saml-core-2.0-os]，以及 OpenID Connect Issuer Identifier [OpenID.Core] 都是可能用作 audience 参数值的示例。 然而，与给定 授权服务器一起使用的 audience 值必须在该服务器内唯一， 以确保它们被正确解释为预期类型的值。可以使用多个 audience 参数来指明 已颁发令牌打算用于列出的多个受众。 audience 和 resource 参数可以一起使用， 以通过逻辑名称和资源 URI 的混合形式指明 多个目标服务。
scope
OPTIONAL。一个由空格分隔、区分大小写的 字符串列表，如 第 3.3 节 of [RFC6749] 所定义，它允许客户端在令牌将被使用的 服务或资源上下文中指定所请求安全令牌的期望范围。 范围的值及其相关语义是服务特定的，并预期会在相关服务 文档中描述。
requested_token_type
OPTIONAL。 一个标识符，如 第 3 节 所述，用于表示所请求安全令牌的类型。 如果未指定所请求类型，则已颁发令牌的类型由 授权服务器自行决定，并且可能由 resource 或 audience 参数指明的服务或资源的需求知识 所决定。
subject_token
REQUIRED。 一个安全令牌，表示 该请求所代表的一方的身份。 通常，此令牌的主体将是 为响应该请求而颁发的安全令牌的主体。
subject_token_type
REQUIRED。 一个标识符，如 第 3 节 所述，用于指明 subject_token 参数中安全令牌的类型。
actor_token
OPTIONAL。 一个安全令牌，表示 行动方的身份。通常，这将是被授权使用 所请求安全令牌并代表主体行事的一方。
actor_token_type
一个标识符，如 第 3 节 所述，用于指明 actor_token 参数中安全令牌的类型。 当请求中存在 actor_token 参数时，这是 REQUIRED， 但否则 MUST NOT 包含。

在处理请求时，授权服务器 MUST 对所指明的令牌 类型执行适当的验证过程；如果存在参与者令牌，也 必须对其所指明的令牌类型执行适当的验证过程。 任何特定令牌的有效性标准和细节超出了 本文档的范围，并且特定于相应的令牌类型及其内容。

在没有一次性使用或其他特定于令牌类型的语义时，执行 令牌交换的行为不会影响主体令牌或参与者令牌的有效性。 此外，交换是一次性事件，不会在输入令牌和输出令牌之间创建紧密联结， 因此（例如）虽然输出令牌的过期时间可能受输入令牌的影响， 但并不期望输入令牌的续期或延期会反映在 输出令牌的属性中。传播 令牌吊销事件可能仍然是适当或可取的。然而，这并不是 STS 协议的一般属性，而是特定于某个实现、令牌类型或部署。

2.1.1. 资源、 受众和范围之间的关系

在请求令牌时，客户端可以通过 audience 和 resource 参数指明其打算使用该令牌的期望目标 服务，也可以使用 scope 参数指明 所请求令牌的期望范围。 此类请求的语义是：客户端正在请求一个具有所请求范围、 并且可在所有所请求目标服务上使用的令牌。实际上， 该令牌所请求的访问权是所有目标服务上所有范围的笛卡尔积。

授权服务器可能不愿或无法满足任何令牌请求，但当所请求访问权非常宽泛时， 请求无法满足的可能性会显著更高。 因此，在缺乏部署中各系统关系的特定知识时， 客户端应谨慎考虑所请求访问的广度，尤其是 目标服务的数量。授权服务器可以使用 第 2.2.2 节 中定义的 invalid_target 错误码，告知 客户端其同时请求访问的目标服务过多。

2.2. 响应

授权服务器使用来自令牌端点的普通 OAuth 2.0 响应来响应令牌交换请求，如 第 5 节 of [RFC6749] 所规定。以下小节提供了更多细节和 说明。

2.2.1. 成功 响应

如果请求有效并满足授权服务器的所有策略和其他条件， 则通过使用 "application/json" 媒体类型 将以下参数添加到 HTTP 响应的实体正文中来构造成功令牌响应， 如 [RFC8259] 所规定， 并使用 HTTP 200 状态码。 这些参数通过在顶层添加每个参数，序列化为 JavaScript Object Notation (JSON) 结构。 参数名称和字符串值作为 JSON 字符串包含。 数值作为 JSON 数字包含。参数的顺序 无关紧要，并且可以变化。

access_token
REQUIRED。授权服务器为响应 令牌交换请求而颁发的安全令牌。 此处使用 第 5.1 节 of [RFC6749] 中的 access_token 参数来承载所请求的 令牌，这使本令牌交换协议能够使用为令牌端点定义的现有 OAuth 2.0 请求和响应构造。 标识符 access_token 是出于历史 原因使用的，而已颁发的令牌不必是 OAuth 访问令牌。
issued_token_type
REQUIRED。一个标识符，如 第 3 节 所述， 用于表示已颁发安全令牌的表示形式。
token_type
REQUIRED。一个不区分大小写的值，用于指定使用已颁发 访问令牌的方法，如 第 7.1 节 of [RFC6749] 所规定。 它向客户端提供有关如何利用访问 令牌访问受保护资源的信息。例如，Bearer 值，如 [RFC6750] 所规定， 表示已颁发的安全令牌是 bearer 令牌，客户端 可以按原样呈现它，而不需要除令牌本身内容之外的任何额外资格证明。 请注意，此参数的含义不同于 issued_token_type 参数的含义，后者声明的是 已颁发安全令牌的表示形式；术语 "token type" 更 通常用于表示安全令牌的结构或语法表示形式， 正如本规范中所有 *_token_type 参数那样。 如果 已颁发令牌不是访问令牌，或者不能作为访问令牌使用，那么 使用 token_type 值 N_A 表示 OAuth 2.0 token_type 标识符在该上下文中不适用。
expires_in
RECOMMENDED。授权服务器颁发的 令牌的有效生命周期，以秒为单位。很多时候，客户端没有意愿或能力 检查令牌内容，而此参数提供了一种一致且与令牌类型无关的 指示，表明该令牌预期可保持有效多久。 例如，值 1800 表示令牌将从响应生成时起 三十分钟后过期。
scope
如果已颁发安全令牌的范围与客户端请求的范围相同， 则 OPTIONAL； 否则为 REQUIRED。
refresh_token
OPTIONAL。 当交换是将一个临时凭据（subject_token）换为一个不同的临时凭据（已颁发 令牌）以在其他上下文中使用时，通常不会颁发刷新令牌。 在令牌交换的客户端需要能够在原始凭据不再有效时 仍访问资源的情况下，可以颁发刷新令牌 （例如，user-not-present 或离线场景，其中不再有任何用户 与客户端保持活动会话）。 本规范的配置文件或部署应清楚记录客户端在何种条件下应预期 在 urn:ietf:params:oauth:grant-type:token-exchange 授权类型请求的响应中收到刷新令牌。

2.2.2. 错误响应

如果请求本身无效，或者 subject_token 或 actor_token 因任何原因无效，或者根据策略不可接受， 则授权服务器 MUST 构造一个 错误响应，如 第 5.2 节 of [RFC6749] 所规定。 error 参数的值 MUST 是 invalid_request 错误码。

如果授权服务器不愿或无法为 resource 或 audience 参数指明的任何目标服务颁发令牌， 则在错误响应中 SHOULD 使用 invalid_target 错误码。

授权 服务器 MAY 使用 error_description 包含关于错误原因的附加信息，如 第 5.2 节 of [RFC6749] 所讨论。

也可以酌情使用其他错误码。

2.3. 令牌交换示例

以下示例演示了一个假设的令牌交换，其中 OAuth 资源服务器 在交换期间承担客户端的角色。它 将在受保护资源请求中收到的访问令牌交换为一个新 令牌，用于调用后端服务 （示例中的额外换行和缩进仅用于显示目的）。

图 1 显示资源服务器接收到一个 受保护资源请求，该请求在 Authorization 头中包含 OAuth 访问令牌，如 第 2.1 节 of [RFC6750] 所规定。 

 GET /resource HTTP/1.1
 Host: frontend.example.com
 Authorization: Bearer accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
图 1: 受保护资源 请求

在 图 2 中，资源服务器在令牌交换中承担 客户端的角色，并且 图 1 请求中的访问令牌使用 第 2.1 节 所规定的请求发送到授权服务器。 subject_token 参数的值承载访问令牌， 而 subject_token_type 参数的值 指明它是 OAuth 2.0 访问令牌。资源服务器作为 客户端使用其标识符和密钥，通过 HTTP Basic 认证方案向 授权服务器进行认证。 resource 参数指明了 已颁发令牌将被使用的后端服务位置 <https://backend.example.com/api>。 

 POST /as/token.oauth2 HTTP/1.1
 Host: as.example.com
 Authorization: Basic cnMwODpsb25nLXNlY3VyZS1yYW5kb20tc2VjcmV0
 Content-Type: application/x-www-form-urlencoded

 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
 &resource=https%3A%2F%2Fbackend.example.com%2Fapi
 &subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
 &subject_token_type=
  urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
图 2: 令牌交换请求

授权服务器验证客户端凭据和令牌 交换请求中呈现的 subject_token。 根据 resource 参数，授权服务器能够确定要应用于请求的 适当策略，并颁发适合在 <https://backend.example.com> 使用的令牌。 图 3 中所示响应的 access_token 参数包含新令牌， 它本身是一个有效期为一分钟的 bearer OAuth 访问令牌。该令牌恰好是 JWT；然而，其结构和格式对 客户端是不透明的，因此 issued_token_type 仅指明它是访问令牌。 

 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-cache, no-store

 {
  "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQiOiJo
    dHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2FzLmV
    4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1MzMsIn
    N1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQedw6rx
    f59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIWvmDCM
    y5-kdXjwhw",
  "issued_token_type":
      "urn:ietf:params:oauth:token-type:access_token",
  "token_type":"Bearer",
  "expires_in":60
 }
图 3: 令牌交换响应

然后，资源服务器可以使用新获得的访问令牌向 后端服务器发出请求，如 图 4 所示。

 GET /api HTTP/1.1
 Host: backend.example.com
 Authorization: Bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQ
    iOiJodHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2
    FzLmV4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1M
    zMsInN1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQe
    dw6rxf59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIW
    vmDCMy5-kdXjwhw
图 4: 后端受保护资源 请求

可在 附录 A 中找到其他示例。

3. 令牌类型标识符

本规范中的若干参数使用标识符作为值来 描述所涉及的令牌。 具体而言，它们是请求中的 requested_token_type、 subject_token_type 和 actor_token_type 参数，以及响应中的 issued_token_type 成员。 令牌类型标识符是 URI。 令牌交换既可以处理由其他方颁发的令牌，也可以处理来自 给定授权服务器的令牌。对于前者，令牌类型标识符指明 语法（例如 JWT 或 SAML 2.0），以便授权服务器能够解析它；对于后者， 它指明 给定授权服务器颁发该令牌的用途（例如 access_token 或 refresh_token）。

本规范定义了以下令牌类型标识符。 其他 URI MAY 用于指明其他令牌类型。

urn:ietf:params:oauth:token-type:access_token
表示该令牌是由给定授权服务器颁发的 OAuth 2.0 访问令牌。
urn:ietf:params:oauth:token-type:refresh_token
表示该令牌是由给定授权服务器颁发的 OAuth 2.0 刷新令牌。
urn:ietf:params:oauth:token-type:id_token
表示该令牌是 [OpenID.Core] 第 2 节中定义的 ID Token。
urn:ietf:params:oauth:token-type:saml1
表示该令牌是 base64url 编码的 SAML 1.1 [OASIS.saml-core-1.1] 断言。
urn:ietf:params:oauth:token-type:saml2
表示该令牌是 base64url 编码的 SAML 2.0 [OASIS.saml-core-2.0-os] 断言。

值 urn:ietf:params:oauth:token-type:jwt，由 第 9 节 of [JWT] 定义，表示该令牌是 JWT。

访问令牌和 JWT 之间的区别很微妙。 访问令牌表示委派的授权决定，而 JWT 是一种令牌格式。 访问令牌可以格式化为 JWT，但并不一定必须如此。而 JWT 很可能是访问令牌，但并非所有 JWT 都是访问令牌。 本规范的意图是，urn:ietf:params:oauth:token-type:access_token 作为一个指示符，表示该令牌是由相关授权服务器颁发的典型 OAuth 访问令牌， 对客户端不透明， 并且能够以与从该授权服务器获得的任何其他访问令牌相同的方式使用。 （它很可能是 JWT，但客户端不知道也无需知道这一事实。） 而 urn:ietf:params:oauth:token-type:jwt 则专门用于表示正在请求或发送 JWT（可能是在跨域用例中，JWT 被用作授权 授予，以便从另一个授权服务器获得访问令牌，如 [RFC7523] 所促进的那样）。

请注意，对于本质上是二进制的令牌，用于传递它们的 URI 需要与适合在 HTTP 和 OAuth 中使用的 base64 或其他 编码语义相关联。

4. JSON Web Token 声明和自省响应参数

定义机制来在令牌中表达委派，以及表达委派或 身份模拟的授权，是很有用的。 尽管本文描述的令牌交换协议可与 任何类型的令牌一起使用，但本节定义了声明，用于专门为 JWT 以及 OAuth 2.0 Token Introspection [RFC7662] 响应表达此类 语义。针对其他类型令牌的类似定义是可能的，但超出了 本规范范围。

请注意，本文未建立但在示例和描述中使用的声明， 例如 iss、sub、 exp 等，由 [JWT] 定义。

4.1. "act"（参与者）声明

act（actor）声明提供了一种 在 JWT 中表达已发生委派并标识 被委派权限的行动方的方法。act 声明值是一个 JSON 对象，并且 JSON 对象中的成员是标识参与者的声明。 构成 act 声明的声明用于标识并可能 提供关于参与者的附加信息。例如， iss 和 sub 两个声明的组合可能是唯一标识 参与者所必需的。

然而，act 声明中的声明仅涉及参与者的身份， 而不像顶层声明那样与包含它的 JWT 的有效性相关。 因此，非身份声明（例如 exp、nbf 和 aud）在 act 声明中使用时没有意义，因此不使用。

图 5 展示了 JWT Claims Set 中的 act （actor）声明。令牌本身的声明是关于 user@example.com 的，而 act 声明表示 admin@example.com 是当前参与者。 

 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "nbf":1443904077,
   "sub":"user@example.com",
   "act":
   {
     "sub":"admin@example.com"
   }
 }
图 5: 参与者声明

可以通过将一个 act 声明嵌套在另一个声明中来表达委派链。 最外层的 act 声明表示当前参与者，而嵌套的 act 声明表示先前的参与者。时间上最早的参与者嵌套得最深。 嵌套的 act 声明 充当历史轨迹，将初始请求和主体 与在到达当前参与者之前所经历的各个委派步骤连接起来。 从这个意义上说，当前参与者被认为 包含整个授权/委派历史，自然导向 此处描述的嵌套结构。

为了应用访问控制策略，令牌的使用者 MUST 只考虑令牌的 顶层声明以及由 act 声明标识为当前参与者的一方。 任何嵌套 act 声明所标识的先前参与者 仅供参考，不应纳入访问控制决策。

图 6 中的以下示例展示了 JWT Claims Set 中嵌套的 act（actor）声明。 令牌本身的声明是关于 user@example.com 的，而 act 声明 表示 系统 <https://service16.example.com> 是当前参与者，而 <https://service77.example.com> 是先前的参与者。 这样的令牌可能是 service16 在来自 service77 的调用中收到令牌， 并将其交换为适合调用 service26 的令牌时产生的结果， 同时授权服务器在新颁发的令牌中记录了该情形。 

 {
   "aud":"https://service26.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904100,
   "nbf":1443904000,
   "sub":"user@example.com",
   "act":
   {
     "sub":"https://service16.example.com",
     "act":
     {
       "sub":"https://service77.example.com"
     }
   }
 }
图 6: 嵌套参与者声明

当作为 OAuth 令牌自省响应的顶层成员包含时，act 与同名声明具有相同的语义和格式。

4.2. "scope"（范围）声明

scope 声明的值是一个 JSON 字符串，其中包含与令牌关联的 以空格分隔的范围列表，格式如 第 3.3 节 of [RFC6749] 所述。

图 7 展示了 JWT Claims Set 中的 scope 声明。 

 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "nbf":1443904077,
   "sub":"dgaf4mvfs75Fci_FL3heQA",
   "scope":"email profile phone address"
 }
图 7: 范围声明

OAuth 2.0 Token Introspection [RFC7662] 已经定义了 scope 参数，用于传达与令牌关联的范围。

4.3. "client_id"（客户端 标识符）声明

client_id 声明承载请求该令牌的 OAuth 2.0 [RFC6749] 客户端的 客户端标识符。

图 8 中的以下示例展示了 JWT Claims Set 中的 client_id 声明， 表示一个标识符为 "s6BhdRkqt3" 的 OAuth 2.0 客户端。 

 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "sub":"user@example.com",
   "client_id":"s6BhdRkqt3"
 }
图 8: 客户端标识符声明

OAuth 2.0 Token Introspection [RFC7662] 已经定义了 client_id 参数，作为请求该令牌的 OAuth 2.0 客户端的客户端标识符。

4.4. "may_act"（已授权 参与者）声明

may_act 声明表明一方被授权 成为参与者并代表另一方行事。 例如，当 subject_token 被 提交到令牌端点以进行令牌交换请求时， 主体令牌中的 may_act 声明可由授权 服务器用于确定客户端（或 actor_token 中标识的一方）是否被授权参与所请求的委派或 身份模拟。 声明值是一个 JSON 对象，并且 JSON 对象中的成员是标识 被断言有资格代表包含该声明的 JWT 所标识一方行事的那一方的声明。 构成 may_act 声明的声明用于标识并可能提供关于已授权参与者的附加信息。 例如，iss 和 sub 两个声明的组合有时是唯一标识已授权参与者所必需的， 而 email 声明可能用于提供关于 该方的其他有用信息。

然而，may_act 声明中的声明仅涉及该方的身份， 而不像顶层声明那样与包含它的 JWT 的有效性相关。 因此，诸如 exp、nbf 和 aud 之类的声明在 may_act 声明中使用时没有意义，因此不使用。

图 9 展示了 JWT Claims Set 中的 may_act 声明。 令牌本身的声明是关于 user@example.com 的，而 may_act 声明 表示 admin@example.com 被授权代表 user@example.com 行事。 

 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "nbf":1443904077,
   "sub":"user@example.com",
   "may_act":
   {
     "sub":"admin@example.com"
   }
 }
图 9: 已授权参与者声明

当作为 OAuth 令牌自省响应的顶层成员包含时， may_act 与同名声明具有相同的语义和格式。

5. 安全考虑事项

第 10 节 of [RFC6749] 中的许多指导， 即 The OAuth 2.0 Authorization Framework 中的安全考虑事项， 在这里也适用。 此外，[RFC6819] 为 OAuth 提供了附加安全考虑事项，并且 [OAUTH-SECURITY] 已根据 OAuth 2.0 最初发布以来的部署经验和出现的新威胁 更新了安全指导。

[JWT] 中讨论的所有常规安全问题， 尤其是关于比较 URI 和处理未识别值的问题， 在这里也适用。

此外，委派和身份模拟都会引入独特的 安全问题。每当一个主体被委派另一个主体的权利时， 滥用的可能性都是一个关注点。建议使用 scope 声明（以及其他典型约束， 例如有限的令牌生命周期）来 缓解此类滥用的可能性，因为它限制了 被委派权利可以被行使的上下文。

6. 隐私考虑事项

在本文所述功能上下文中使用的令牌 可能包含隐私敏感信息，并且为防止 此类信息披露给非预期方，MUST 仅通过 加密信道传输，例如 Transport Layer Security (TLS)。在希望防止某些 信息披露给客户端的情况下，令牌 MUST 加密给其 预期接收者。部署 SHOULD 确定最少必要 数据量，并仅在已颁发令牌中包含这些信息。 在某些情况下，数据最小化可能包括仅表示 匿名或假名用户。

7. IANA 考虑事项

7.1. OAuth URI 注册

IANA 已在 "OAuth Parameters" 注册表 [IANA.OAuth.Parameters] 的 "OAuth URI" 子注册表中注册以下值。"OAuth URI" 子注册表由 [RFC6755] 建立。

  • URN: urn:ietf:params:oauth:grant-type:token-exchange
  • 通用名称：OAuth 2.0 的令牌交换授权类型
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 2.1 节
  • URN: urn:ietf:params:oauth:token-type:access_token
  • 通用名称：OAuth 2.0 访问令牌的令牌类型 URI
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 3 节
  • URN: urn:ietf:params:oauth:token-type:refresh_token
  • 通用名称：OAuth 2.0 刷新令牌的令牌类型 URI
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 3 节
  • URN: urn:ietf:params:oauth:token-type:id_token
  • 通用名称：ID Token 的令牌类型 URI
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 3 节
  • URN: urn:ietf:params:oauth:token-type:saml1
  • 通用名称：base64url 编码的 SAML 1.1 断言的令牌类型 URI
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 3 节
  • URN: urn:ietf:params:oauth:token-type:saml2
  • 通用名称：base64url 编码的 SAML 2.0 断言的令牌类型 URI
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 3 节

7.2. OAuth 参数 注册

IANA 已在 "OAuth Parameters" 注册表 [IANA.OAuth.Parameters] 的 "OAuth Parameters" 子注册表中注册以下值。 "OAuth Parameters" 子注册表由 [RFC6749] 建立。

  • 参数名称：audience
  • 参数使用位置：令牌请求
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 2.1 节
  • 参数名称：requested_token_type
  • 参数使用位置：令牌请求
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 2.1 节
  • 参数名称：subject_token
  • 参数使用位置：令牌请求
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 2.1 节
  • 参数名称：subject_token_type
  • 参数使用位置：令牌请求
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 2.1 节
  • 参数名称：actor_token
  • 参数使用位置：令牌请求
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 2.1 节
  • 参数名称：actor_token_type
  • 参数使用位置：令牌请求
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 2.1 节
  • 参数名称：issued_token_type
  • 参数使用位置：令牌响应
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 2.2.1 节

7.3. OAuth 访问令牌 类型注册

IANA 已在 "OAuth Parameters" 注册表 [IANA.OAuth.Parameters] 的 "OAuth Access Token Types" 子注册表中注册以下访问令牌类型。 "OAuth Access Token Types" 子注册表由 [RFC6749] 建立。

  • 类型名称：N_A
  • 附加令牌端点响应参数：无
  • HTTP 认证方案：无
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 2.2.1 节

7.4. JSON Web Token 声明 注册

IANA 已在 "JSON Web Token (JWT)" 注册表 [IANA.JWT] 的 "JSON Web Token Claims" 子注册表中注册以下 Claims。 "JSON Web Token Claims" 子注册表由 [JWT] 建立。

  • Claim Name: act
  • Claim Description: Actor
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 4.1 节
  • Claim Name: scope
  • Claim Description: Scope Values
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 4.2 节
  • Claim Name: client_id
  • Claim Description: Client Identifier
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 4.3 节
  • Claim Name: may_act
  • Claim Description: Authorized Actor - the party that is authorized to become the actor
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 4.4 节

7.5. OAuth 令牌 自省响应注册

IANA 已在 "OAuth Parameters" 注册表 [IANA.OAuth.Parameters] 的 "OAuth Token Introspection Response" 注册表中注册以下值。 "OAuth Token Introspection Response" 注册表由 [RFC7662] 建立。

  • Name: act
  • Description: Actor
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 4.1 节
  • Name: may_act
  • Description: Authorized Actor - the party that is authorized to become the actor
  • 变更控制者：IESG
  • 规范文档：RFC 8693 的 第 4.4 节

8. 参考文献

8.1. 规范性参考文献

[IANA.JWT]
IANA, "JSON Web Token (JWT)", <https://www.iana.org/assignments/jwt>.
[IANA.OAuth.Parameters]
IANA, "OAuth Parameters", <https://www.iana.org/assignments/oauth-parameters>.
[JWT]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/info/rfc7519>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986]
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <https://www.rfc-editor.org/info/rfc3986>.
[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <https://www.rfc-editor.org/info/rfc6749>.
[RFC7662]
Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, , <https://www.rfc-editor.org/info/rfc7662>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/info/rfc8259>.

8.2. 资料性参考文献

[OASIS.saml-core-1.1]
Maler, E., Mishra, P., and R. Philpott, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1", OASIS Standard oasis-sstc-saml-core-1.1, , <https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf>.
[OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, , <http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.
[OAUTH-RESOURCE]
Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", Work in Progress, Internet-Draft, draft-ietf-oauth-resource-indicators-08, , <https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-08>.
[OAUTH-SECURITY]
Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "OAuth 2.0 Security Best Current Practice", Work in Progress, Internet-Draft, draft-ietf-oauth-security-topics-13, , <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13>.
[OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", , <https://openid.net/specs/openid-connect-core-1_0.html>.
[RFC6750]
Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, , <https://www.rfc-editor.org/info/rfc6750>.
[RFC6755]
Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, DOI 10.17487/RFC6755, , <https://www.rfc-editor.org/info/rfc6755>.
[RFC6819]
Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, , <https://www.rfc-editor.org/info/rfc6819>.
[RFC7521]
Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, , <https://www.rfc-editor.org/info/rfc7521>.
[RFC7523]
Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, , <https://www.rfc-editor.org/info/rfc7523>.
[WS-Trust]
Nadalin, A., Ed., Goodner, M., Ed., Gudgin, M., Ed., Barbir, A., Ed., and H. Granqvist, Ed., "WS-Trust 1.4", , <https://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html>.

附录 A. 其他令牌交换 示例

以下各节提供了两个令牌交换示例， 分别展示身份模拟和委派 （额外的换行和缩进仅用于显示目的）。

A.1. 身份模拟令牌 交换示例

A.1.1. 令牌交换 请求

在以下令牌交换请求中，客户端正在请求一个具有 身份模拟语义的令牌（仅有 subject_token 而没有 actor_token 时不可能进行委派）。 客户端告知授权服务器，它需要一个令牌，以便在逻辑名称为 urn:example:cooperation-context 的目标服务中使用。 

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

 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
 &audience=urn%3Aexample%3Acooperation-context
 &subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc
   zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI
   uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTA2MDAsIm5iZiI6MTQ0MTkwOTAwMCwic
   3ViIjoiYmRjQGV4YW1wbGUubmV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN
   0b3J5In0.PRBg-jXn4cJuj1gmYXFiGkZzRuzbXZ_sDxdE98ddW44ufsbWLKd3JJ1VZ
   hF64pbTtfjy4VXFVBDaQpKjn5JzAw
 &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
图 10: 令牌交换 请求

A.1.2. 主体令牌 声明

前述请求中的 subject_token 是 JWT，并且 解码后的 JWT Claims Set 如此处所示。该 JWT 旨在由授权服务器在特定时间窗口内使用。 该 JWT 的主体（bdc@example.net）是 正在代表其请求新令牌的一方。

  {
    "aud":"https://as.example.com",
    "iss":"https://original-issuer.example.net",
    "exp":1441910600,
    "nbf":1441909000,
    "sub":"bdc@example.net",
    "scope":"orders profile history"
  }
图 11: 主体令牌声明

A.1.3. 令牌交换 响应

下面所示令牌交换 响应中的 access_token 参数包含客户端请求的新令牌。 响应的其他参数表明该令牌是一个 bearer 访问令牌， 将在一小时后过期。

 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-cache, no-store

 {
  "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4
    6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l
    eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic3ViIjoiYmRjQGV4YW1wbGUub
    mV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN0b3J5In0.rMdWpSGNACTvnF
    uOL74sYZ6MVuld2Z2WkGLmQeR9ztj6w2OXraQlkJmGjyiCq24kcB7AI2VqVxl3wSW
    nVKh85A",
  "issued_token_type":
    "urn:ietf:params:oauth:token-type:access_token",
  "token_type":"Bearer",
  "expires_in":3600
 }
图 12: 令牌交换 响应

A.1.4. 已颁发令牌 声明

已颁发令牌的解码后 JWT Claims Set 如下所示。新的 JWT 由 授权服务器颁发，并打算由逻辑名称为 urn:example:cooperation-context 的系统实体在其过期前的任何时间 使用。 该 JWT 的主体（sub） 与用于发出请求的令牌主体相同， 这实际上使客户端能够通过使用该令牌，在逻辑名称为 urn:example:cooperation-context 的系统实体处模拟该主体。 

  {
    "aud":"urn:example:cooperation-context",
    "iss":"https://as.example.com",
    "exp":1441913610,
    "sub":"bdc@example.net",
    "scope":"orders profile history"
  }
图 13: 已颁发令牌声明

A.2. 委派令牌 交换示例

A.2.1. 令牌交换 请求

在以下令牌交换请求中，客户端正在请求一个令牌， 并同时提供 subject_token 和 actor_token。 客户端告知授权服务器，它需要一个令牌，以便在逻辑名称为 urn:example:cooperation-context 的目标服务中使用。 授权服务器处的策略规定，已颁发令牌应为复合令牌。 

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

 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
 &audience=urn%3Aexample%3Acooperation-context
 &subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc
   zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI
   uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInNjb3BlIjoic3RhdHVzIGZlZ
   WQiLCJzdWIiOiJ1c2VyQGV4YW1wbGUubmV0IiwibWF5X2FjdCI6eyJzdWIiOiJhZG1
   pbkBleGFtcGxlLm5ldCJ9fQ.4rPRSWihQbpMIgAmAoqaJojAxj-p2X8_fAtAGTXrvM
   xU-eEZHnXqY0_AOZgLdxw5DyLzua8H_I10MCcckF-Q_g
 &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
 &actor_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwczo
   vL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXIuZ
   XhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInN1YiI6ImFkbWluQGV4YW1wbGU
   ubmV0In0.7YQ-3zPfhUvzje5oqw8COCvN5uP6NsKik9CVV6cAOf4QKgM-tKfiOwcgZ
   oUuDL2tEs6tqPlcBlMjiSzEjm3yBg
 &actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
图 14: 令牌交换 请求

A.2.2. 主体令牌 声明

前述请求中的 subject_token 是 JWT，并且 解码后的 JWT Claims Set 如此处所示。该 JWT 旨在由授权服务器 在特定过期时间之前使用。 该 JWT 的主体 （user@example.net）是 正在代表其请求新令牌的一方。

  {
    "aud":"https://as.example.com",
    "iss":"https://original-issuer.example.net",
    "exp":1441910060,
    "scope":"status feed",
    "sub":"user@example.net",
    "may_act":
    {
      "sub":"admin@example.net"
    }
  }
图 15: 主体令牌声明

A.2.3. 参与者令牌声明

前述请求中的 actor_token 是 JWT，并且 解码后的 JWT Claims Set 如此处所示。此 JWT 也 旨在由授权服务器 在特定过期时间之前使用。 该 JWT 的主体 （admin@example.net）是 将使用所请求安全令牌的参与者。

  {
    "aud":"https://as.example.com",
    "iss":"https://original-issuer.example.net",
    "exp":1441910060,
    "sub":"admin@example.net"
  }
图 16: 参与者令牌声明

A.2.4. 令牌交换 响应

下面所示令牌交换 响应中的 access_token 参数包含客户端请求的新令牌。 响应的其他参数表明该令牌是一个 JWT， 将在一小时后过期，并且访问令牌类型不适用， 因为已颁发令牌不是访问令牌。

 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-cache, no-store

 {
  "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4
    6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l
    eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic2NvcGUiOiJzdGF0dXMgZmVlZ
    CIsInN1YiI6InVzZXJAZXhhbXBsZS5uZXQiLCJhY3QiOnsic3ViIjoiYWRtaW5AZX
    hhbXBsZS5uZXQifX0.3paKl9UySKYB5ng6_cUtQ2qlO8Rc_y7Mea7IwEXTcYbNdwG
    9-G1EKCFe5fW3H0hwX-MSZ49Wpcb1SiAZaOQBtw",
  "issued_token_type":"urn:ietf:params:oauth:token-type:jwt",
  "token_type":"N_A",
  "expires_in":3600
 }
图 17: 令牌交换 响应

A.2.5. 已颁发令牌 声明

已颁发令牌的解码后 JWT Claims Set 如下所示。新的 JWT 由 授权服务器颁发，并打算由逻辑名称为 urn:example:cooperation-context 的系统实体在其过期前的任何时间使用。 该 JWT 的主体（sub） 与用于发出请求的 subject_token 的主体相同。 该 JWT 的参与者（act）与用于发出请求的 actor_token 的主体相同。 这表示委派，并标识 admin@example.net 为当前参与者，即被委派 权限来代表 user@example.net 行事的一方。 

  {
    "aud":"urn:example:cooperation-context",
    "iss":"https://as.example.com",
    "exp":1441913610,
    "scope":"status feed",
    "sub":"user@example.net",
    "act":
    {
      "sub":"admin@example.net"
    }
  }
图 18: 已颁发令牌声明

致谢

本规范是在 OAuth 工作组内开发的，该工作组 包括数十位积极且专注的参与者。 它是在 Hannes Tschofenig、Derek Atkins 和 Rifaat Shekh-Yusef 的主席任内完成的， 同时 Kathleen Moriarty、Stephen Farrell、Eric Rescorla、Roman Danyliw 和 Benjamin Kaduk 担任 安全领域主任。

以下个人为本规范贡献了想法、反馈和措辞： Caleb Baker、 Vittorio Bertocci、 Mike Brown、 Thomas Broyer、 Roman Danyliw、 William Denniss、 Vladimir Dzhuvinov、 Eric Fazendin、 Phil Hunt、 Benjamin Kaduk、 Jason Keglovitz、 Torsten Lodderstedt、 Barry Leiba、 Adam Lewis、 James Manger、 Nov Matake、 Matt Miller、 Hilarie Orman、 Matthew Perry、 Eric Rescorla、 Justin Richer、 Adam Roach、 Rifaat Shekh-Yusef、 Scott Tomilson、 以及 Hannes Tschofenig。

作者地址

Michael B. Jones
Microsoft
URI: https://self-issued.info/
Anthony Nadalin
Microsoft
Brian Campbell (编辑)
Ping Identity
John Bradley
Yubico
Chuck Mortimore
Visa