令牌交换流程图和流程

以下是场景：您在 Salesforce 平台之外托管客户入口网站。为了确保客户可以访问他们需要的所有信息，您将入口网站与各种不同的应用程序和微服务集成在一起。例如，您使用第三方应用程序处理付款和发货，并使用 Amazon Web Services 管理客户数据。您不希望客户登录所有这些不同的服务，因此您也可以使用 Okta 作为第三方身份提供商。这样，客户可以登录 Okta，并在入口网站中访问他们需要的所有信息。

您需要一种在入口网站中管理支持个案的方法，并且您知道 Salesforce 可以完成这项工作。但是，您希望确保客户可以直接在您的入口网站访问他们的个案信息，而无需登录 Salesforce。换句话说，您需要一种使 Salesforce 适应现有系统的方法。这就是令牌交换流的来源。通过该流，您可以确保客户在通过 Okta 登录入口网站时可以访问他们的 Salesforce 数据。

要了解令牌交换流如何提供这种体验，让我们看看流的顺序。有关此流中请求和响应的更多详细说明，请参阅设置令牌交换流。

在流开始时，假设最终用户已经通过 Okta（身份提供商）登录到客户入口网站（客户端）。客户端使用外部客户端应用程序框架与 Salesforce 集成。

• (1) 最终用户请求访问受保护的 Salesforce 资源。例如，在客户入口网站中，用户单击按钮访问他们的支持个案信息。
• (2) 因为用户已经登录，所以客户端拥有来自身份提供商的有效令牌。
• (3) 客户端应用程序向 Salesforce /services/oauth2/token 端点发送 POST 请求。该请求包括多个参数，这取决于您的用例。它至少必须包含这些参数。
  • grant_type 参数，告诉 Salesforce 该应用程序想要使用令牌交换流。
  • 带有来自身份提供商的令牌的 subject_token 参数。
  • subject_token_type 参数，指示令牌的类型，例如不透明访问令牌、刷新令牌、ID 令牌、SAML 声明或 JSON Web 令牌 (JWT)。
  • client_id，告诉 Salesforce 哪个外部客户端应用程序为此客户端注册。
• (4) Salesforce OAuth 运行时收到 POST 请求并验证它。如果请求有效，Salesforce 会将身份提供商的令牌传递给 Apex 令牌交换处理器。
• (5) Apex 令牌交换处理器验证令牌。作为验证的一部分，处理器可以调出身份提供商。
  

  备注 对身份提供商的这种标注是可选项，取决于您如何开发处理程序。如果您不包含此标注，流会继续步骤 7。
• (6)（可选）如果调用，身份提供商会返回信息，以帮助处理程序验证令牌。
• (7) 处理程序将令牌中的主题映射到 Salesforce 主题。要获取有关主题的更多信息，处理器可以再次调用身份提供商。
  

  备注 对身份提供商的第二个标注也是可选的。如果您不包含此标注，流会继续步骤 9。
• (8)（可选）如果调用，身份提供商会将用户信息返回到令牌交换处理器。
• (9) 如果处理程序找到现有 Salesforce 用户，将返回用户。如果找不到现有用户，它会设置新的用户对象，并将其返回到 Salesforce 进行自动插入。
• (10) Salesforce OAuth 运行时会检查处理程序是否返回现有用户。如果没有，Salesforce 会代表令牌交换处理器插入新用户。
• (11) Salesforce OAuth 运行时向客户端返回访问令牌。令牌响应还包括任何其他请求的令牌和参数，例如刷新令牌或 ID 令牌。
• (12) 客户端收到带有访问令牌和其他请求的令牌的令牌响应。
• (13)（可选）如有必要，客户端可以调用 Salesforce 用户信息端点，以获取有关用户的更多信息并完成登录。
• (14) 客户端现在可以使用访问令牌向受保护的 Salesforce 端点发出经过身份验证的请求。
• (15) Salesforce 授予对请求的资源的访问权限。

在流结束时，最终用户可以通过身份提供商登录，并在客户端应用程序中访问他们的 Salesforce 数据，而无需直接登录 Salesforce。例如，他们可以通过 Okta 登录，并在您的客户入口网站中访问 Salesforce 提供的支持个案信息。