一、 OAuth2.0 基础
概念：OAuth2.0 一个授权框架，它允许用户让第三方应用访问该用户在某服务的特定私有资源，但是不提供账号密码消息给第三方应用
角色：
- resource owner（资源所有者）
- resource server（资源服务器）
- client（客户端）：代表资源所有者并且经过所有者授权去访问受保护的资源的应用程序
- authorization server（授权服务器）：在成功验证资源所有者并获得授权后向客户端发出访问令牌
授权模式：
Authorization code（授权码模式）
标准的 Server 授权模式，非常适合 Server 端的 Web 应用。一旦资源的拥有者授权访问他们的数据之后，他们将会被重定向到 Web 应用并在 URL 的查询参数中附带一个授权码（code）。在客户端里，该 code 用于请求访问令牌（access_token）。并且该令牌交换的过程是两个服务端之前完成的，防止其他人甚至是资源拥有者本人得到该令牌。另外，在该授权模式下可以通过 refresh_token 来刷新令牌以延长访问授权时间，也是最为复杂的一种方式。
Implicit Grant（隐式模式）
该模式是所有授权模式中最简单的一种，并为运行于浏览器中的脚本应用做了优化。当用户访问该应用时，服务端会立即生成一个新的访问令牌（access_token）并通过URL的#hash段传回客户端。这时，客户端就可以利用JavaScript等将其取出然后请求API接口。该模式不需要授权码（code），当然也不会提供refresh token以获得长期访问的入口。
Resource Owner Password Credentials（密码模式）
自己有一套用户体系，这种模式要求用户提供用户名和密码来交换访问令牌（access_token）。该模式仅用于非常值得信任的用户，例如API提供者本人所写的移动应用。虽然用户也要求提供密码，但并不需要存储在设备上。因为初始验证之后，只需将 OAuth 的令牌记录下来即可。如果用户希望取消授权，因为其真实密码并没有被记录，因此无需修改密码就可以立即取消授权。token本身也只是得到有限的授权，因此相比最传统的 username/password 授权，该模式依然更为安全。
Client Credentials（客户端模式）
没有用户的概念，一种基于 APP 的密钥直接进行授权，因此 APP 的权限非常大。它适合像数据库或存储服务器这种对 API 的访问需求。
二、OAuth2.0授权流程
- (A) 客户端向资源所有者请求其授权
- (B) 客户端收到资源所有者的授权许可，这个授权许可是一个代表资源所有者授权的凭据
- (C) 客户端向授权服务器请求访问令牌，并出示授权许可
- (D) 授权服务器对客户端身份进行认证，并校验授权许可，如果都是有效的，则发放访问令牌
- (E) 客户端向资源服务器请求受保护的资源，并出示访问令牌
- (F) 资源服务器校验访问令牌，如果令牌有效，则提供服务
三、Refresh Token流程
刷新的流程如图所示：
- (A) 客户端请求获取访问令牌，并向授权服务器提供授权许可
- (B) 授权服务器对客户端身份进行认证，并校验授权许可，如果校验通过，则发放访问令牌和刷新令牌
- (C) 客户端访问受保护的资源，并向资源服务器提供访问令牌
- (D) 资源服务器校验访问令牌，如果校验通过，则提供服务
- (E) 重复(C)和(D)直到访问令牌过期。如果客户端直到访问令牌已经过期，则跳至(G)，否则不能继续访问受保护的资源
- (F) 自从访问令牌失效以后，资源服务器返回一个无效的令牌错误
- (G) 客户端请求获取一个新的访问令牌，并提供刷新令牌
- (H) 授权服务器对客户端进行身份认证并校验刷新令牌，如果校验通过，则发放新的访问令牌（并且，可选的发放新的刷新令牌）
