Authentication — Custom Auth Provider Plugin

好，同学们，今天咱们来看一个非常实用的技术点——怎么用Apex为PSO，也就是专业服务自动化应用，创建一个自定义的基于OAuth的身份验证提供程序插件。 听起来可能有点绕，其实说白了，就是你们公司可能用了一些第三方的服务来管理用户登录，比如Concur这种报销系统。Salesforce本身已经内置了对谷歌、Facebook这些常见身份提供商的支持，但如果你们的提供商不在那个列表里，我们就需要自己写一个插件，让Salesforce能跟它对接。 这个插件的核心是什么？就是要去扩展一个抽象类，叫做`Auth.AuthProviderPluginClass`。这个类已经给我们搭好了骨架，我们要做的就是去填充细节，实现它规定的三个方法。 这三个方法各司其职，掌控了整个OAuth认证流程的三个关键步骤。 第一个方法叫`initiate()`。它的作用是，当用户点击“登录”按钮时，我们需要构建一个URL，把用户引导到那个第三方的身份提供商页面，就像给他们指一条路，说：“你去那个网站，先验证自己的身份。”所以，`initiate`方法就是去构建并返回这个认证用的URL。 第二个方法叫`deliverCallback()`。用户在那个第三方网站登录成功之后，对方会把用户送回Salesforce，同时带回来一个授权码。这个时候，我们写的`deliverCallback`方法就会被触发。它要负责拿着这个授权码，再去向身份提供商换取真正的访问令牌和可选的刷新令牌。换好之后，把这些令牌包装在一个叫做`AuthProviderTokenResponse`的对象里，交给Salesforce系统。这样，Salesforce就知道：“哦，这个人确实已经通过验证了，这是他的通行证。” 第三个方法叫`getUserInfo()`。光有通行证还不行，我们还得知道这个人是谁，他的邮箱、姓名这些基本信息是什么。所以，`getUserInfo`方法会用拿到的访问令牌，去调用那个第三方提供商的API，把用户的详细信息取回来，然后按照Salesforce要求的格式，组织成一个`Auth.UserData`对象并返回。这样，Salesforce就能把这些信息映射到内部的用户记录上。 这里有个很有意思的例子——Concur。官方文档里有一个Concur身份提供程序的完整实现。因为在有些认证流程里，回来的信息可能是HTML格式的页面，而不是整洁的JSON数据。所以那个Concur示例就特别展示了怎么解析HTML，把需要的信息提取出来，非常接地气。 最后，作为开发者，我们当然要保证代码质量，写测试类是少不了的。由于这些方法都要和外部网络打交道，不可能每次都真的去连接外部服务做测试。所以我们就用`HttpCalloutMock`来模拟网络响应。通过实现这个Mock接口，我们可以伪造出身份提供商返回的各种数据，这样就可以在完全不联网的情况下，完整地测试我们的插件逻辑了。 这样一来，只要实现了这三个方法，再配上Mock测试，你就能为任何支持OAuth的外部服务打造一个专属的登录通道，让Salesforce的集成能力变得更加灵活和强大。好，今天的内容就到这里，大家下去可以试着看看文档里的Concur例子，动手感受一下。