了解 OAuth/OIDC 中的令牌交换

在 RFC 8693 中引入的令牌交换是一种 OAuth 扩展，允许受信任的客户端将现有令牌交换为具有不同属性或范围的新令牌。此机制特别适用于服务、应用程序或最终用户通过预授权的令牌获得正常的 OAuth 访问令牌，而无需完成完整的 OAuth 流程。

与授权码流程的比较#

首先，让我们来看看 OAuth 授权码流程，它是获取访问令牌的最常见流程。

这是令牌交换流程：

重定向#

主要区别在于，在授权码流程中，客户端应用程序将用户重定向到授权服务器以获取访问令牌。在令牌交换中，客户端应用程序可以与授权服务器交换令牌而无需涉及用户重定向。

这是因为在授权码流程中，客户端应用程序不被“信任”，需要知道用户的凭证才能获得访问令牌。在令牌交换中，客户端应用程序被信任已经从用户那里获得了令牌，授权服务器将验证该令牌并签发新令牌。

令牌发行者和令牌交换服务#

在令牌交换流程中，“授权服务器”现在有两个参与者：

1. 令牌发行者：向客户端应用程序颁发主题令牌。
2. 令牌交换服务：验证主题令牌并向客户端应用程序颁发新令牌。

令牌交换服务与授权码流程中的“授权服务器”相同，令牌发行者可以是第三方身份提供者，或从“授权服务器”拆分为专用服务。

何时使用令牌交换？#

令牌交换流程可以在无用户交互的情况下进行，这在以下场景中很有用：

• 模拟： 允许服务（例如，后台微服务）或管理员用户在不暴露完整用户凭据的情况下代表用户执行操作。
• 自动化： 允许受信任的服务自动执行操作，无需人工干预，或执行自动化测试。
• 与其他 IdP 的集成： 在不同的身份系统之间翻译令牌，以保持无缝的用户体验并有效管理权限，一个常见场景是将 SSO 令牌翻译为下游服务的令牌。
• 迁移： 将令牌从一个授权服务器迁移到另一个，例如，从遗留系统迁移到现代 OAuth/OIDC 兼容系统。

令牌交换过程#

交换新访问令牌是最常见的用例，我们将以此为例。不仅限于访问令牌，令牌交换还可以用于颁发其他类型的令牌，如刷新令牌、ID 令牌等。

客户端应用程序#

要执行令牌交换，必须向授权服务器注册客户端应用程序。

并且客户端应用程序在启动令牌交换流程之前必须拥有一个 subject_token，此令牌通常由授权服务器或受信任的第三方身份提供者授予。拥有此令牌后，客户端应用程序现在可以“信任”地交换令牌，而无需用户的凭证和交互。

令牌交换请求#

客户端向授权服务器的令牌端点发送请求以交换现有令牌。这包括 subject_token（正在交换的令牌）以及可选的目标受众、范围和令牌类型。

1. grant_type: 必须。此参数的值必须是 urn:ietf:params:oauth:grant-type:token-exchange，表示正在执行令牌交换。
2. subject_token: 必须。用户的 PAT。
3. subject_token_type: 必须。subject_token 参数中提供的安全令牌的类型。此参数的一个常见值是 urn:ietf:params:oauth:token-type:access_token，但可以根据正在交换的令牌而有所不同。
4. resource: 可选。资源指示器，用于指定访问令牌的目标资源。
5. audience: 可选。访问令牌的受众，指明令牌的预期接收者，如果未指定 audience，授权服务器可能会使用 resource 的值。
6. scope: 可选。请求的范围。

此外，请求需要包含客户端信息，可以编码为基本认证头或作为表单数据发送。

以下是一个请求示例：

Logto 中的令牌交换#

Logto 原生支持令牌交换，包括模拟和个人访问令牌。