Salesforce 知识点：Connected App

Salesforce Connected App（连接应用程序）是 Salesforce 生态中用于实现第三方应用与 Salesforce 平台安全集成的机制。它允许外部应用（如自定义网站、移动应用、其他系统等）通过 Salesforce 的 API（如 REST API、SOAP API 等）访问 Salesforce 中的数据和功能，同时提供严格的身份验证、授权和访问控制。

核心作用

简单来说，Connected App 是第三方应用与 Salesforce 之间的“安全网关”，解决了两个关键问题：

1. 身份验证：确保访问 Salesforce 的外部应用是可信的。
2. 授权：控制外部应用能访问哪些 Salesforce 数据（如客户信息、订单记录）和功能（如创建、修改数据）。

主要功能与场景

1. API 访问授权
   第三方应用通过 Connected App 获得访问 Salesforce API 的权限，实现数据交互。例如：

   • 企业自建的 CRM 系统需要同步 Salesforce 中的客户数据。
   • 电商网站通过 API 向 Salesforce 推送新订单。

2. OAuth 认证支持
   基于 OAuth 2.0 协议，支持多种认证流程（如授权码流程、密码流程等），避免第三方应用直接存储 Salesforce 用户名和密码，提升安全性。

   • 例如：用户在第三方应用中点击“使用 Salesforce 登录”，通过 Connected App 完成身份验证，无需重复输入密码。

3. 访问范围控制
   管理员可通过“权限集”或“配置文件”限制 Connected App 的访问范围：

   • 仅允许访问特定对象（如 Account、Contact）。
   • 限制操作权限（如只读、可编辑）。
   • 设定 API 调用频率限制，防止滥用。

4. 集成外部系统
   支持与非 Salesforce 系统的集成，例如：

   • 营销自动化工具（如 HubSpot）通过 Connected App 读取 Salesforce 中的线索数据。
   • 内部 ERP 系统通过 API 向 Salesforce 同步产品库存信息。

关键组成

• 消费者密钥（Consumer Key）：Connected App 的唯一标识，类似“用户名”。
• 消费者密钥（Consumer Secret）：与密钥配对的机密信息，类似“密码”，用于验证应用身份。
• 回调 URL（Callback URL）：OAuth 认证成功后，Salesforce 跳转的第三方应用地址（用于传递授权码）。
• API 权限：配置该应用可访问的 Salesforce API 类型（如 REST、SOAP、Bulk API 等）。

使用流程

1. 在 Salesforce 中创建 Connected App，配置基本信息（名称、回调 URL）、API 权限、认证方式等。
2. 生成 Consumer Key 和 Consumer Secret，提供给第三方应用。
3. 第三方应用使用这些凭证，通过 OAuth 流程获取访问令牌（Access Token）。
4. 应用携带访问令牌调用 Salesforce API，实现数据交互。

OAuth 2.0 认证流程

在 Salesforce Connected App 中，以下选项用于启用不同的 OAuth 2.0 认证流程，以适配不同的集成场景（如服务器间通信、用户授权、设备登录等）。以下是每个选项的具体含义和适用场景：

1. Enable Client Credentials Flow（启用客户端凭证流程）

• 核心逻辑：无用户参与，直接通过 Connected App 的 Consumer Key 和 Consumer Secret 获取访问令牌（Access Token），用于服务器到服务器的后台集成。
• 适用场景：
  • 两个系统（如 ERP 与 Salesforce）之间的自动数据同步（无需用户交互）。
  • 后台服务定期调用 Salesforce API（如夜间批量数据处理）。
• 特点：
  • 令牌基于应用身份，而非用户身份，权限由 Connected App 配置的“应用权限集”决定。
  • 无需用户登录，适合无人值守的自动化场景。

2. Enable Authorization Code and Credentials Flow

（注：完整名称通常为 Enable Authorization Code Flow，可能包含扩展的“Authorization Code with PKCE”）

• 核心逻辑：最常用的用户授权流程，需用户手动登录 Salesforce 并授权，第三方应用获取“授权码”后兑换访问令牌，代表用户操作。
• 适用场景：
  • 第三方网站/应用需要以用户身份访问 Salesforce 数据（如用户在自建 CRM 中查看 Salesforce 客户信息）。
  • 支持“用 Salesforce 账号登录”第三方应用（类似 OAuth 社交登录）。
• 特点：
  • 安全性高，令牌关联用户身份，权限受用户自身权限和 Connected App 配置双重限制。
  • 扩展的 Authorization Code with PKCE 适用于移动应用（防止授权码被拦截）。

3. Enable Device Flow（启用设备流程）

• 核心逻辑：针对无浏览器的设备（如智能电视、物联网设备），用户通过其他设备（手机/电脑）扫码或访问链接授权，设备最终获取令牌。
• 适用场景：
  • 智能设备需要访问 Salesforce 数据（如工厂设备通过 Salesforce IoT 云同步数据）。
  • 无输入界面的终端（如 POS 机）关联 Salesforce 账号。
• 流程简述：
  1. 设备向 Salesforce 请求“用户码”和“验证 URL”。
  2. 用户在手机上打开 URL 并输入用户码，完成授权。
  3. 设备轮询 Salesforce 获取访问令牌。

4. Enable JWT Bearer Flow（启用 JWT 承载流程）

• 核心逻辑：通过预签名的 JWT（JSON Web Token） 获取访问令牌，无需用户交互，适用于信任的系统间集成（如企业内部系统）。
• 适用场景：
  • 企业内部应用（如 HR 系统）向 Salesforce 同步数据，且应用已被 Salesforce 信任（预先配置公钥）。
  • 需要高安全性、低延迟的服务器间通信（避免频繁输入密码）。
• 特点：
  • 应用需用私钥签名 JWT，Salesforce 通过预先配置的公钥验证签名，确认身份。
  • 令牌可关联特定用户（JWT 中指定 subject 为 Salesforce 用户名），权限基于该用户。

5. Enable Token Exchange Flow（启用令牌交换流程）

• 核心逻辑：允许将一个系统的访问令牌兑换为 Salesforce 的访问令牌，适用于多系统间的身份联合（如基于 SAML 或 OIDC 的单点登录场景）。
• 适用场景：
  • 用户已通过企业 SSO 系统（如 Microsoft Entra ID、Okta）登录，无需再次输入 Salesforce 密码，直接用 SSO 令牌兑换 Salesforce 令牌。
  • 跨平台身份传递（如从 Heroku 应用兑换 Salesforce 令牌）。
• 特点：
  • 依赖外部身份提供商（IdP）的令牌，需 Salesforce 信任该 IdP。
  • 简化用户体验，实现“一次登录，多系统访问”。

这些流程的核心目的是在不同场景下安全地获取 Salesforce API 访问令牌，选择时需根据：

• 是否有用户参与（如后台集成选 Client Credentials/JWT，用户交互选 Authorization Code）；
• 集成设备类型（如无浏览器设备选 Device Flow）；
• 安全性要求（如高信任场景选 JWT，跨系统 SSO 选 Token Exchange）。

选项用于强化 OAuth

在 Salesforce Connected App 的安全配置中，这些选项用于强化 OAuth 认证流程的安全性，防止令牌泄露、伪造等风险。以下是每个选项的具体含义和作用：

1. Require secret for Web Server Flow（Web 服务器流程需要密钥）

• 适用场景：针对 Authorization Code Flow（授权码流程）（即“Web Server Flow”）。
• 作用：强制要求第三方应用在使用授权码兑换访问令牌时，必须提供 Connected App 的 Consumer Secret（消费者密钥）。
• 安全性：避免授权码被恶意拦截后，未经验证就兑换令牌（因为攻击者通常无法获取 Consumer Secret）。
• 建议：生产环境必须启用，尤其是服务器端应用（如网站后台），确保“授权码→令牌”环节的身份验证。

2. Require secret for Refresh Token Flow（刷新令牌流程需要密钥）

• 适用场景：当应用使用 Refresh Token（刷新令牌） 获取新的访问令牌时（访问令牌过期后，通过刷新令牌续期）。
• 作用：强制要求应用在使用刷新令牌时，必须同时提供 Consumer Secret，验证应用身份。
• 安全性：防止刷新令牌泄露后被滥用（即使攻击者拿到刷新令牌，若无 Consumer Secret 也无法获取新令牌）。
• 建议：启用，尤其是长期有效的刷新令牌场景（如桌面应用）。

3. Require Proof Key for Code Exchange (PKCE) extension for Supported Authorization Flows（要求 PKCE 扩展）

• 适用场景：主要针对 Authorization Code Flow，尤其是移动应用、单页应用（SPA）等无法安全存储 Consumer Secret 的场景。
• 作用：强制应用使用 PKCE（Proof Key for Code Exchange） 机制：
  1. 应用生成随机的“代码挑战”（Code Challenge）和“代码验证器”（Code Verifier）。
  2. 授权时传递 Code Challenge，兑换令牌时必须提供对应的 Code Verifier。
• 安全性：防止授权码被拦截后重放攻击（攻击者无法生成匹配的 Code Verifier，即使拿到授权码也无法兑换令牌）。
• 建议：对移动应用、SPA 必须启用；服务器端应用也建议启用，进一步提升安全性。

4. Enable Refresh Token Rotation（启用刷新令牌轮换）

• 适用场景：使用刷新令牌续期访问令牌的场景。
• 作用：每次用旧刷新令牌获取新访问令牌时，Salesforce 会同时生成一个新的刷新令牌，并使旧刷新令牌失效。
• 安全性：限制刷新令牌的生命周期，即使旧令牌泄露，也会因失效而无法使用，降低长期风险。
• 注意：启用后，应用必须及时存储新的刷新令牌（否则下次无法续期）。
• 建议：生产环境强烈推荐启用，尤其对高敏感数据访问的应用。

5. Issue JSON Web Token (JWT)-based access tokens for named users（为指定用户颁发 JWT 格式的访问令牌）

• 作用：默认情况下，Salesforce 访问令牌是 opaque（不透明）的字符串，而启用此选项后，访问令牌将以 JWT 格式生成，包含可解析的用户信息（如用户名、过期时间、权限范围等）。
• 适用场景：第三方应用需要验证令牌合法性（无需调用 Salesforce API），或从令牌中直接获取用户上下文（如用户 ID、组织 ID）。
• 安全性：JWT 由 Salesforce 用私钥签名，应用可通过公钥验证签名，确保令牌未被篡改。
• 注意：仅影响访问令牌格式，不改变令牌的权限和有效期。

这些配置的核心是通过“身份验证强化”“令牌生命周期管理”“防篡改机制”提升 Connected App 的安全性。实际配置时需结合应用类型（服务器端/移动端/SPA）和风险等级：

• 移动应用/SPA：必须启用 PKCE 和 Refresh Token Rotation。
• 服务器端应用：启用 Require secret for Web Server/Refresh Token Flow 和 Refresh Token Rotation。
• 需自主验证令牌的场景：启用 JWT-based access tokens。

**Enable SAML **

在 Salesforce Connected App 中启用 SAML 后，主要用于实现基于 SAML 的单点登录（SSO），即用户通过外部身份提供商（IdP，如 Okta、Azure AD、ADFS 等）登录后，无需再次输入 Salesforce 凭据即可访问该 Connected App。以下是具体的使用流程和配置要点：

前提条件

1. 已在 Salesforce 中创建 Connected App 并启用 SAML（在“API (Enable OAuth Settings)”下方勾选“SAML”）。
2. 已配置外部身份提供商（IdP），并获取 IdP 的 SAML 元数据（通常是一个 XML 文件或 URL）。

核心步骤：配置与使用流程

第一步：在 Salesforce 中配置 SAML 相关参数

1. 进入 Connected App 详情页（Setup → Apps → App Manager → 找到你的应用 → 点击“编辑”）。
2. 在“SAML 配置”部分填写关键信息：
   • Entity ID：Salesforce 作为服务提供商（SP）的唯一标识，通常格式为 https://<你的 Salesforce 域名>.my.salesforce.com 或自定义 URL。
   • ACS URL（Assertion Consumer Service URL）：Salesforce 接收 SAML 断言的地址，格式通常为 https://<你的 Salesforce 域名>.my.salesforce.com/services/auth/saml/callback/<Connected App ID>（可在页面下方自动生成）。
   • Subject Type：选择 SAML 断言中用于标识用户的字段（如“Username”，需与 Salesforce 用户名匹配）。
   • Name ID Format：指定 NameID 的格式（如 urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified）。
   • IdP 元数据：上传外部 IdP 的 SAML 元数据 XML 文件（或输入元数据 URL），Salesforce 会自动解析 IdP 的登录 URL、签名证书等信息。
3. 保存配置， Salesforce 会生成 SP 元数据（可在页面下载，用于配置 IdP）。

第二步：在外部身份提供商（IdP）中配置 Salesforce 作为服务提供商（SP）

以 Okta 为例，配置步骤大致如下：

1. 在 Okta 管理后台创建一个新的应用集成，选择“SAML 2.0”。
2. 上传 Salesforce 生成的 SP 元数据（或手动输入 Entity ID 和 ACS URL）。
3. 配置 SAML 断言属性：确保 IdP 生成的 SAML 断言中包含 Salesforce 所需的用户标识（如 NameID 对应 Salesforce 用户名）。
4. 启用该应用，并将其分配给需要访问 Salesforce 的用户。

第三步：用户通过 SSO 访问 Connected App

1. 用户登录外部 IdP（如 Okta 门户），点击已配置的 Salesforce Connected App 图标。
2. IdP 对用户身份进行验证（如输入公司账号密码），验证通过后生成 SAML 断言（包含用户身份、权限等信息，并用 IdP 私钥签名）。
3. IdP 将 SAML 断言通过浏览器重定向发送到 Salesforce 的 ACS URL。
4. Salesforce 接收断言后，验证签名（使用 IdP 公钥，来自之前上传的元数据），并检查断言中的用户标识（如 NameID 是否存在于 Salesforce 中）。
5. 验证通过后，Salesforce 为用户创建会话，直接跳转至 Connected App 对应的资源（如自定义应用页面、API 访问授权等），用户无需再次登录。

第四步：测试与验证

• 测试 SSO 流程：从 IdP 门户发起访问，确认能否成功跳转至 Salesforce 并自动登录。
• 查看 SAML 断言：可通过浏览器开发者工具（Network 面板）捕获 SAML 响应，检查断言内容是否正确（需解码 XML）。
• 排查问题：若登录失败，查看 Salesforce 日志（Setup → Identity → SAML 登录历史）或 IdP 日志，常见原因包括：签名验证失败（证书不匹配）、用户标识不匹配（NameID 与 Salesforce 用户名不一致）、ACS URL 错误等。

核心用途

启用 SAML 后，Connected App 的主要价值在于：

1. 企业级单点登录：用户通过企业统一身份平台（如 Azure AD）访问 Salesforce 应用，无需记忆多个账号密码。
2. 集中身份管理：通过 IdP 统一控制用户权限（如离职员工在 IdP 中被禁用后，自动失去 Salesforce 访问权限）。
3. 合规与安全：满足企业对身份认证的合规要求（如多因素认证 MFA 可在 IdP 层统一配置）。

总结来说，SAML 配置完成后，用户通过外部 IdP 发起访问，全程无需手动输入 Salesforce 凭据，实现“一次登录，多系统访问”的无缝体验，同时提升企业身份管理的安全性和效率。

总结

Connected App 是 Salesforce 对外开放生态的核心机制，通过标准化的认证和授权流程，让第三方应用安全、可控地集成 Salesforce 数据和功能，广泛用于企业系统集成、跨平台数据同步、自定义应用开发等场景。