Salesforce Oauth2.0详解及工具

前言

在Salesforce项目中，很多地方涉及到Integration，除标准的Integration之外，还有许多Custom Integration（Rest/Soap）。那么在Custom中，我们如何保障数据安全或者说如何保障连入Salesforce的接口是经过安全验证的呢？在这里Salesforce提供了标准的Oauth2.0实现方案，也就是说我们通过在Integration中加入Oauth2.0的验证来保障安全。而且更为方便的是我们只需在连接过程中加入Oauth2.0的验证方式，但具体的验证规则则由Salesforce托管实现。笔者简写了一个测试工具（在本文末尾），可以直观的体验效果。

Oauth2.0

首先我们需要强调的是Oauth2.0是一种规范，并不是具体的技术实现方案。这里有点类似 JAVA 的 JPA，JPA并不实现ORM方案。但是它制定了一系列规范，供其它厂商去实现，例如Hibernate。了解这个之后，我们在来看Oauth2.0也是如此。Oauth2.0同样制定了一系列规范，由各厂商分别去实现各自产品的方案。这里说一些题外话，其实Oauth2.0规范是一种比较良好/简易的授权方案，目前实现的厂商非常多，例如Wechat、Alipay、Baidu等。附Oauth2.0官网： 点击打开链接

Oauth2.0术语解释

• consumer key：也叫client key，用来标识Connected App
• consumer secret：也叫client secret，类似于Connected App密码
• direct uri：客户端与服务端交互的回访地址
• access token：通行标记，与security token区分开，用来通行Salesforce Org
• refresh token：用来刷新access token
• security token：安全标记，在IDE或者不安全登陆方式上加强认证的方式

Salesforce中Oauth2.0的实现方式

在Salesforce中实现Oauth2.0有三种方案：

• Web Server：服务端可以安全的保障consumer secret（Oauth2.0访问凭据）
• User Agent：服务端没有安全机制保障consumer secret
• Username Password：应用程序可以直接访问用户凭据

以上解释来源于Salesforce API。实际过程中笔者的理解是Web Server方式可以获得Refresh Token，可以实现自刷新Access Token。而其余两种方案并不会获得Refresh Token，这个是一个本质的区别。另：Salesforce Oauth2.0认证过程均支持Json格式。

1. Web Server：流程如下图

通过上图我们可以看出Web Server获得access token方式 大致需要五步：引导用户到授权界面（或者发起授权操作）—> 获取Code—> 置换access token。

Web Server方式可以获得refresh token，应妥善保管相关数据。

关键步骤：

• • POST https://{login}.salesforce.com/services/oauth2/authorize Params： response_type client_id client_secret redirect_uri
  • POST https://{login}.salesforce.com/services/oauth2/token Params： grant_type client_secret client_id redirect_uri code
    

2. User Agent ：流程如下图

通过上图我们可以看出User Agnet方式获得access token大致需要两步：引导用户到授权界面（或者发起授权操作）—> （code由Salesforce内置执行）获取access token。但是此种方式并没有refresh token，也就是并没有能力自刷新access token。

关键步骤：

• POST https://{login}.salesforce.com/services/oauth2/authorize Params： response_type client_id redirect_uri

3. Username Password：流程如下图

通过上图我们可以看出Username Password方式获得access token只需一步：引导用户到授权界面（或者发起授权操作）。这种方式最为简单、方便。但是由于在直接返回，尤其是Web应用很难保障其输入数据安全。推荐测试使用。

关键步骤：

• • POST https://login.salesforce.com/services/oauth2/token  Params： response_type client_id client_secret username password(包含security token)

以上的内容讲述了Oauth2.0的认证方式及实现。我们需要清楚的是Oauth的实现是独立于Integration或其他方案，也就是说在进行其他对接时应与Oauth解耦，不应与Oauth绑定在一起。在进行对接时我们在Http请求中加入Header — Authorization: Bearer {access_token}即可。在设计的时候区别开来，会为后期的应用减少不少麻烦。

心得

• Salesforce的Oauth2.0实现了Oauth2.0的规范（有点绕哈），实现方式和开发方式为我们的不同自定义应用提供了相应的入口，在实际开发过程中，根据具体需要采取不同的方案；
• Salesforce Oauth2.0的访问规则是由Connected App去决定，所以根据具体的业务，最好有针对性的进行设计和维护；
• Salesforce安全认证不仅是Oauth2.0，也可以直接通过username+password或者SessionId的方式通过验证或其他方式；
• 在具体的Integration中接触这一块的概率比较小，因为他已经被设计者实现了除非是你设计或提议，但是了解这一块能让我们更深入了解SFDC安全机制。
• 建议实现单独的Oauth2.0方案，这样相当于连接了你的平台和Salesforce。在之后的开发、维护会节约你大量时间和麻烦；
• 笔者在这里写了一个简易的Oauth2.0测试页面（链接：点击打开链接，请忽略https安全），可以方便的体验三种方式的差异以及进行测试。这一部分基本由JS完成，但由于CORS的限制，有一部分的请求仍需后台执行。另：不提供Oauth2.0托管服务。

参考

https://resources.docs.salesforce.com/208/latest/en-us/sfdc/pdf/api_rest.pdf