OAuth 授权流

例如，当您打开 Salesforce 移动应用程序访问您的 Salesforce 数据时，您将启动 OAuth 2.0 授权流。在此流中，您的 Salesforce 组织是托管受保护资源的资源服务器。Salesforce 移动应用程序是请求访问的客户端。您是资源所有者，允许 Salesforce 移动应用程序随时通过网络访问和管理您的 Salesforce 数据。您的 Salesforce 组织作为授权服务器，通过颁发访问标记来授予对 Salesforce 移动应用程序的访问权限。让我们逐步复习一下该流。

1. 打开 Salesforce 移动应用程序。
2. 将显示身份验证提示，您可以在其中输入用户名和密码。
3. Salesforce 移动应用程序会将您的凭据发送给 Salesforce，并启动 OAuth 授权流。
4. Salesforce 发送移动应用访问和刷新标记，以确认用户和移动应用程序的成功验证。
5. 您可以批准请求，授予对 Salesforce 移动应用程序的访问权限。
6. Salesforce 移动应用程序启动。

在该初始流之后，当会话处于活动状态时，Salesforce 移动应用程序会立即启动。如果会话过时，Salesforce 移动应用程序会使用其初始授权中的刷新标记来获取更新的会话。

将此方法与为客户端应用程序提供用户名和密码并代表您访问资源服务器进行比较。客户端应用程序有意模仿您，并精确地对数据拥有相同访问权限。如果您不再信任该客户端应用程序，您必须在资源服务器中更改密码；这不仅非常不方便，而且存在安全风险。鉴于此原因，OAuth 授权是一个更好的解决方案。

OAuth 授权流和外部客户端应用程序

除 SAML 声明流外，所有 OAuth 授权流都需要您定义外部客户端应用程序。外部客户端应用程序框架使第三方应用程序能够使用 API 和标准协议（例如 SAML、OAuth 和 OpenID Connect）与 Salesforce 集成。外部客户端应用程序使用这些协议来验证、授权和集成外部应用程序和服务提供商。与 Salesforce 集成的外部应用程序可以在客户成功平台、设备、SaaS 订阅或其他平台上运行。在以上示例中，Salesforce 移动应用程序使用外部客户端应用程序与您的组织集成。

备注 用户可以授权外部客户端应用程序多次访问受保护的数据，例如笔记本电脑、台式计算机和移动设备。默认情况下，每个用户对每个外部客户端应用程序拥有五个授权。如果用户在达到组织的限制后尝试授予对外部客户端应用程序的访问权限，则未使用时间最长的访问令牌将被撤销。在用户授予访问权限后，使用 Web 服务器流的较新的 OAuth 2.0 外部客户端应用程序将被批准用于更多设备。用户代理流程每次都需要用户批准。

OAuth 授权流用例

作为 Salesforce 开发人员，您可以从几个 OAuth 授权流中进行选择。为您的应用程序选择正确的流时，请考虑以下用例。

重要 一些流拥有重要的安全注意事项。例如，在使用 Web 服务器流时，您必须安全存储客户端密码。我们建议避免用户代理和用户名密码流，因为它们传输凭据。相反，选择可让应用程序不必管理、存储和保护凭据的流。

• 无头身份流
  您可以使用无头身份 API 为平台外应用程序配置登录、注册、无密码登录等。无头身份流仅适用于外部用户，也称为客户和合作伙伴。
• 在应用程序中创建本机单点登录体验
  通过 OAuth 2.0 Web 服务器流和用户-客服人员流中的可选参数，您可以构建单点登录 (SSO) 体验，就像您的第三方应用程序与外部身份提供商集成在一起。通过该流程，您可以将 OAuth 流链接到 SSO 流，同时保持对应用程序中体验的控制。Experience Cloud 站点支持此参数，因此您可以使用此功能将 SSO 添加到无头身份实施。My Domain 也支持此参数。
• 面向 Web 应用程序集成的 OAuth 2.0 Web 服务器流
  要将外部 Web 应用程序与 Salesforce API 集成，请使用 OAuth 2.0 Web 服务器流，它实施OAuth 2.0 授权代码授权类型。通过此流，托管 Web 应用程序的服务器必须能够保护由客户端 ID 和客户端密码定义的外部客户端应用程序的身份。
• 面向桌面或移动应用程序集成的 OAuth 2.0 用户代理流
  通过 OAuth 2.0 用户代理流，用户授权桌面或移动应用程序使用外部或嵌入式浏览器访问数据。使用脚本语言（例如 JavaScript）在浏览器中运行的客户端应用程序也可以使用该流。该流使用 OAuth 2.0 隐式授权类型。
• 适用于更新会话的 OAuth 2.0 刷新标记流
  OAuth 2.0 刷新标记流更新由 OAuth 2.0 Web 服务器流或 OAuth 2.0 用户代理流发布的访问标记。
• OAuth 2.0 令牌交换流
  当 Salesforce 只是包括中央身份提供商以及多个应用和微服务的架构的一个组件时，使用 OAuth 2.0 令牌交换流来简化您的集成模式。通过此流，将外部身份提供商的令牌交换为 Salesforce 令牌并授予对 Salesforce 数据的访问权限。
• 适用于混合应用程序的 OAuth 2.0 授权和会话管理
  管理混合应用程序的网络会话对于典型的用户代理或刷新标记流来说非常复杂。在这些流中，混合应用程序设置请求的域 Cookie，并将访问标记桥接到网络会话中。但是访问标记和网络会话在这些流中没有连接。相反，您必须跟踪访问和刷新标记何时到期以及网络会话何时到期，然后手动重新桥接会话以避免服务中断。为了避免这个复杂的过程，请使用 OAuth 2.0 混合应用程序流。这些流将访问和刷新标记与网络会话连接起来，从而为混合应用程序提供直接的网络会话管理。
• 适用于服务器到服务器集成的 OAuth 2.0 JWT 不记名流
  有时，您希望授权服务器访问数据，而不必每次服务器交换信息时都交互登录。对于一些情况，您可以使用 OAuth 2.0 JSON Web 令牌 (JWT) 不记名流。此流会使用证书签名 JWT 请求，且无需显式用户集成。但是，此流确实需要客户端应用程序的事先批准。
• 适用于服务器到服务器集成的 OAuth 2.0 客户端凭据流
  有时，您想要在两个应用程序之间直接共享信息，而无需用户参与。对于这些场景，您可以使用 OAuth 2.0 客户端凭据流。在此流中，客户端应用程序将其在外部客户端应用程序中定义的客户端凭据（它的使用者密钥和使用者密码）交换为访问令牌。此消除了对显式用户交互的需要，尽管它要求您指定集成用户来运行集成。您可以使用此流作为 OAuth 2.0 用户名密码流的更安全的替代方案。
• 适用于外部 API 网关的 OpenID Connect 动态客户端注册
  虽然不是典型的授权流程，但您可以使用 OpenID Connect 动态客户端注册来使您的 Salesforce 实例成为独立的 OAuth 授权服务器，以保护托管在外部 API 网关上的资源。
• 生成初始访问令牌
  通过 OpenID Connect 动态客户端注册，OAuth 2.0 客户端（连接的应用程序）会直接向 Salesforce 注册连接的应用程序。要对这些客户端注册请求进行身份验证，Salesforce 需要初始访问令牌。
• OpenID Connect 令牌自检
  作为授权过程的一部分，标记自检允许所有 OAuth 连接的应用程序检查 OAuth 2.0 访问或刷新标记的当前状态。资源服务器或连接的应用程序将客户端应用程序的客户端 ID 和密码发送到授权服务器，启动 OAuth 授权流。作为该流的一部分，授权服务器验证或自检客户端应用程序的访问标记。如果访问标记为最新且有效，客户端应用程序将被授予访问权限。
• 适用于 IoT 集成的 OAuth 2.0 设备流
  要集成在输入或显示能力有限的设备上运行的应用程序，例如智能电视、电器和其他 IoT 设备，请使用 OAuth 2.0 设备流。命令行应用程序也可以使用该流。通过在支持更多高级输入功能的设备（例如台式机或移动设备）上访问浏览器，用户可以将这些应用程序连接到 Salesforce。
• 用于保护连接设备的 OAuth 2.0 资产标记流
  要将 IoT 设备与 Salesforce API 集成，请使用 OAuth 2.0 资产标记流。资产标记是基于开源标准的 JWT 身份验证标记，可用于验证并保护连接设备的请求。资产标记会找出后端服务的设备，可处理来自设备的数据和事件流。这些资产标记允许使用 Salesforce 平台注册设备数据并将设备链接到有关消费者、客户或联系人的 Salesforce CRM 数据。
• 演示资产标记流程
  要快速演示资产标记，您可以使用资产标记资源管理器演示应用程序。该演示应用程序可简化您在获取访问权限标记并为资产标记进行交换的初始体验。
• 适用于特殊情况的 OAuth 2.0 用户名密码流
  您可以使用用户名-密码流通过连接的应用程序来授权已经拥有用户凭据的客户端。但是，我们建议避免该流，因为它来回传递凭据。只有在资源所有者和客户端之间高度信任、客户端是第一方应用程序、Salesforce 托管数据以及其他授权类型不可用的情况下，才使用它。在这些个案中，设置用户权限，以最小化访问权限，并避免未经授权地访问存储的凭据。
• 阻止授权流以提高安全性
  OAuth 2.0 用户代理和用户名密码流被认为是不安全的，不推荐使用。为了提高安全性，我们强烈建议您在 Salesforce 中阻止这些流，以防止开发人员将它们用于构建新的集成。如果贵组织在 Summer ‘23 或更高版本中创建，用户名-密码流将默认阻止。如果需要，您可以启用用户名-密码流。如果您有使用用户代理或用户名密码流的现有集成，请将它们更新为更安全的 OAuth 2.0 流。您还可以阻止授权代码和凭据流，它用于安全地配置无头登录过程。您可以阻止某些不使用 PKCE 扩展的流。
• 面向先前授权应用程序的 OAuth 2.0 SAML 不记名声明流
  通过 OAuth 2.0 SAML 不记名声明流，客户端可以通过连接的应用程序，通过提供签名的 SAML 2.0 声明来请求 OAuth 访问标记，从而使用以前的授权。应用到 SAML 声明的数字签名会对授权应用程序进行身份验证。SAML 声明是由身份提供商签发并由服务器提供商使用的 XML 安全标记。服务提供商会依赖内容，以出于安全相关目的识别声明主题。
• 用于访问 API的 SAML 声明流
  对于使用 SAML 访问 Salesforce 并希望以相同方式访问 API 的组织而言，SAML 声明流是替代方案。客户端可以使用 SAML 声明与 API 联盟，方式与 Web 单点登录 (Web SSO)的 Salesforce 联盟相同。您可以在没有连接的应用程序的情况下使用该声明流程。
• OAuth 2.0 授权错误
  OAuth 授权期间可能会出现错误。例如，用户拒绝访问连接的应用程序或请求参数不正确。当出现错误时，授权服务器会向带有错误代码的回调 URL 发送错误。
• OAuth 1.0.A 流程
  如果您的组织使用 OAuth 1.0.A 协议，请使用此授权流程通过连接的应用程序将客户端与 Salesforce API 集成在一起。
• OAuth 1.0.A 授权错误代码
  授权期间可能会出现错误。例如，回拨 URL 无效。当 OAuth 1.0.A 流程中出现错误时，Salesforce 会返回错误代码。