Authentication — OAuth 2.0 Token Exchange Handler

今天我们来聊一聊 Salesforce 里一个特别实用的功能——，OAuth 2.0 代币交换，。 想象一下，你有一个很复杂的系统，里面有好几个不同的应用程序，它们都想安全地跟 Salesforce 通信。这时候，我们不能让每个应用都去存一份用户名密码，太不安全了。更好的方式是，它们各自拿一个自己身份提供商（IdP）签发的令牌，然后到 Salesforce 这边来换成 Salesforce 自己的访问令牌，这就叫“代币交换”。 在 Apex 里，我们可以通过扩展一个叫 `Auth.Oauth2TokenExec` 的类来实现这个交换逻辑。这个类有两个特别重要的方法，咱们一个一个来看。 --- ### 1. 验证传来的令牌：`validateIncomingToken()` 这个方法的作用就是：“你拿来的令牌，我得先验一验，看到底是真的还是假的。” 因为不同的系统发出来的令牌格式可能不一样，所以 Salesforce 很聪明地准备了几种验证方式： - ，如果是 JWT 格式的令牌，（一种用点分隔的字符串，很常见），它会用内置工具 `Auth.JWTUtil` 来校验签名和有效期。 - ，如果是不透明令牌，（看起来像一串乱码，没有规律），它就会调身份提供商的“内省端点”，通过 REST 请求去问：“这个令牌长这样，现在还合法吗？” - ，如果是 SAML 断言，，它会用 ML 解析（就是把那段 XML 格式的 SAML 数据解开）来做检查。 检查完以后呢，它会给我们返回一个 `TokenValidationReport` 对象。 这个报告里有啥？非常简单，就三样东西： - 一个，成功标志，（告诉我们令牌合法不合法） - 一些，自定义数据，（可以用来放我们自己的业务信息） - 还有，用户数据，（将来可能跟 Salesforce 里的用户关联起来） --- ### 2. 根据令牌找到对应的 Salesforce 用户：`getUserForTokenSubmit()` 令牌验完了是合法的，那接下来就有一个问题：“这个令牌到底是哪个用户的？” 这个方法就是干这个映射工作的。 它先去查询 Salesforce 里有没有一个现成的用户，对应令牌里标的那个“主题”（比如用户名或者邮箱）。 如果找到了，那就直接用它，省事。 但如果没找到，而我们的配置里有个参数叫 `cannerUser` 是 `true`，那它就自动帮你，建一个新用户，。它会构建一个 User 对象，准备插入到数据库里去。 这里还有个小细节：如果是那种，外部用户，（比如社区用户），光建一个 User 还不够，它还会同时帮你把关联的 ，Contact（联系人），、，Account（账户）， 或者 ，PersonAccount（个人账户）， 一起创建好，这样用户出来就是一个完整的生态，不会缺胳膊少腿。 --- ### 3. 最后一步：权限集的分配用 `@future` 来异步处理 用户建好了，接下来要给他分配权限集，这样他才能干该干的事。 但是呢，如果我们直接在同一个事务里做这件事，很可能会遇到 Salesforce 的一个限制——叫，混合 DML 错误，。 简单说就是，你在一个操作里同时又插用户（Setup 对象）又改别的数据（非 Setup 对象），系统会报错不让干。 所以老师这里教我们一个技巧：，用 `@future` 方法，。 就是把分配权限集这个操作放到一个异步的小任务里，跟主流程分开。这样主流程结账的时候，权限集那块儿还没开始跑，就不会触发混合限制，两全其美。 --- 好了，总结一下，今天我们学了在复杂的多应用系统里，怎么通过 OAuth 2.0 代币交换把外部身份的令牌换成 Salesforce 用户，并且安全地做好权限分配。两个方法：先验令牌，再找用户；最后别忘了用 `@future` 把权限集分配悄悄甩出去。是不是感觉也没那么难？以后遇到第三方集成，你也可以用这个模式，很稳当。 咱们下次课再见！