一、前言

之前在对接支付宝的当面付时，总是涉及到各种授权，常见的第三方授权，涉及到code，token，accessToken 还有各种privateKey，publicKey 等眼花缭乱的概念。只是照着支付宝的文档在进行对接，现在回过头来研究了下，发现它的整个第三方授权体系，就是用的OAuth2.0 的架构。

二、支付宝第三方应用授权逻辑

如下图示（图片来源蚂蚁开放平台）

1.开发者向用户提供授权url 或授权二维码

1.1.用户登录支付宝账号进行授权

1.2.支付宝返回授权code,跳转到开发者指定页面，这样开发者获得授权code

2.1.开发者通过上一步获得的code去换取访问令牌access_token

2.2.支付宝返回access_token，开发者获取到令牌后就可以通过令牌去支付宝上查询用户资源了

这里有一个疑问：为什么在支付宝返回code后，不直接使用访问用户资源，而是要先换取令牌后再通过令牌进行访问用户资源？

三、典型的第三方应用授权

如下图所示，是归纳的整个授权的模型，核心还是在于第2步得到的code，和第4步得到的access_token。

四、OAuth 是什么

OAuth 的英文全称是Open Authorization，它是一种开放授权协议。

OAuth目前共有2个版本，2007年12月的1.0版（之后有一个修正版1.0a）和2010年4月的2.0版，1.0版本存在严重安全漏洞，而2.0版解决了该问题。

五、OAuth2.0 的思路

OAuth 主要是在第三方应用（客户端）和服务商之间设置了一个授权层。第三方应用不能直接登录服务商，只能登录授权层（这个授权层 可以是直接在服务端的服务器上，也可以是专门的认证服务器）。

第三方应用登录授权层所用的令牌与用户密码不同，这里用户在登录授权的时候，可以指定授权层令牌（access_token）的权限范围和有效期。

第三方应用登录授权层后，服务商根据令牌的权限范围和有效期，来向第三方提供用户资源。

六、OAuth2.0 安全机制

OAuth 2.0 协议在设计时，考虑了很多安全因素，下面就是 授权码模式下的一些安全机制：

1.利用更新令牌来延长令牌的授权时间

一般为了安全考虑，授权令牌的有效期不会太长，但是也不能让每次都去获取令牌。那这里的处理机制就是第一次获取令牌的时候，服务端也会回给客户端一个refreshToken，在要刷新令牌的时候，通过refreshToken就可以获取一个新的令牌。

2.第三方应用需要在授权服务器上认证和注册

比如前言中提到，我们作为第三方，需要调用用户的支付宝信息，在使用第三方认证授权前，我们必须要先在支付宝上的认证服务器上进行认证。

OAuth 2.0 协议默认浏览器是一个不安全的环境，所以在授权码模式授权过程中，用户给予授权后，认证服务器不是直接返回访问令牌，而是返回认证码，并通过浏览器重定向给第三方应用。第三方应用需要用认证码换取访问令牌，而换取步骤需要认证服务器认证第三方应用身份并且不通过浏览器，以此保证授权过程的安全性。

这也就解释第二部分的疑问。

3.获取认证码请求中，加入state 参数防止CRSF攻击

CRSF 攻击是跨站点请求伪装。在第三方应用把用户重定向到认证服务器以获取认证码的请求中，需要加入state参数，且认证服务器要返回相同的state参数给第三方应用。CSRF攻击者要想诱导用户授权并插入自己的认证码，且被第三方应用接收，就需要猜出该state参数，这大大增加了CSRF攻击的难度。

---

参考：阮一峰 理解OAuth 2.0