第三方API对接如何设计接口认证

一、OAuth2 认证方式

分四种

• 授权码模式（authorization code）
• 简化模式（implicit）
• 密码模式（resource owner password credentials）
• 客户端模式（client credentials）

授权码模式（authorization code）是功能最完整、流程最严密的授权模式。

这种模式算是正宗的oauth2的授权模式
设计了auth code，通过这个code再获取token
支持refresh token

密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下。一般不支持refresh token。

步骤说明：
（A）用户向客户端提供用户名和密码。
（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。
（C）认证服务器确认无误后，向客户端提供访问令牌。

简化模式（implicit）

这种模式比授权码模式少了code环节，回调url直接携带token
这种模式的使用场景是基于浏览器的应用
这种模式基于安全性考虑，建议把token时效设置短一些
不支持refresh token
implicit模式（隐式模式）和授权码模式(authorization_code)访问差不多，相比之下，少了一步获取code的步骤，而是直接获取token

客户端模式（client credentials）

这种模式直接根据client的id和**即可获取token，无需用户参与
这种模式比较合适消费api的后端服务，比如拉取一组用户信息等
不支持refresh token，主要是没有必要。

请求参数：请求头添加上 client_id和client_secret的basic编码，请求提添加grant_type必须设置为client_credentials
返回结果：accesstoken

二、动态签名认证方式

在每次接口调用时都需要传输以下参数：

• app_id 应用id
• time 当前时间戳
• nonce 随机数
• sign 签名

其中sign签名的生成方式为：使用参数中的
app_id + time + nonce 并在最后追加 app_secrect 的字符串进行md5加密，并全部转换成大写。

如果需要实现参数的防篡改，只需把接口所有的请求参数都作为签名的生成参数即可

优点

安全性最高

1. 服务端使用相同的方式生成签名进行对比认证，无需在网络上传输 app_secrect。
2. 可以防止 中间人攻击。
3. 通过 time 参数判断请求的时间差是否在合理范围内，可防止 重放攻击。
4. 通过 nonce 参数进行幂等性判断。

 缺点

不适用于前端应用使用，js源码会暴露签名的方式与app_secrect

三、Basic认证方式

这是一种较为简单的认证方式，客户端通过明文（Base64编码格式）传输用户名和密码到服务端进行认证。

通过在 Header 中添加key为 Authorization，值为 Basic 用户名:密码的base64编码，字符进行base64编码，最终传值为：

Authorization: Basic base64encode(username+":"+password)

优点

简单，被广泛支持。

缺点

安全性较低，需要配合HTTPS来保证信息传输的安全

1. 虽然用户名和密码使用了Base64编码，但是很容易就可以解码。
2. 无法防止 重放攻击 与 中间人攻击。