Oauth2.0授权方式

引子

OAuth2.0是一套标准。这个标准解决了这样的一个问题。

允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。
OAuth2.0是怎么解决的呢?

给第三方应用一个临时密码,过期作废,而且这个密码的访问权限可由我随时取消。这样就足够安全了。这个临时密码就是access_token。
发放access_token的方法就多种多样了,这些方法叫做授权模式。

OAuth2授权方式

OAuth2为我们提供了四种授权方式：
1.密码模式（resource owner password credentials）
为遗留系统设计(支持refresh token)
2.授权码模式（authorization code）
正宗方式(支持refresh token)
3.简化模式（implicit）
为web浏览器应用设计(不支持refresh token)
4.客户端模式（client credentials）
为后台api服务消费者设计(不支持refresh token)

授权码模式

OAuth定义了四种角色：
resource owner（资源所有者）
resource server（资源服务器）
client（客户端）：代表资源所有者并且经过所有者授权去访问受保护的资源的应用程序
authorization server（授权服务器）：在成功验证资源所有者并获得授权后向客户端发出访问令牌

授权码相对其他三种来说是功能比较完整、流程最安全严谨的授权方式，通过客户端的后台服务器与服务提供商的认证服务器交互来完成。流程如下图所示：

这是一个获取token的流程，以手游使用微信账号，通过微信授权登录为例。
ResourceOwner:用户，玩家
Client:游戏程序
User-Agent：手机/电脑微信程序
对于用户来说，用户希望使用微信账号玩游戏，但是不希望用户名和密码被游戏公司获得，同时又可以方便的登录游戏。
Oauth2.0的做法是，微信端给手游端传送一条授权码，手游端通过授权码，请求授权服务器获取token,然后拿着token去获取用户信息，然后登录进入游戏。
这样，用户在游戏中的信息，存储在手游公司的服务器上面，为游戏公司所有。但是，可以使用微信/QQ来登录游戏，此时手游的用户服务器是微信授权服务器的资源服务器。
这个流程里面，存在相互对立的两个方面。一个方面是客户端Client,另一个方面是AuthorizationServer,ResourceServer,User-Agent组成的服务认证端。

（A）用户访问客户端，后者将前者导向认证服务器。
（B）用户选择是否给予客户端授权。
(C）假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。
（D）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。
（E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。
如果是纯网页的版本，也可以将User-Agent看作授权服务器的登录页面，Client看作资源服务的页面。

简化模式

简化，是对授权码的简化。流程如下：

客户端Client对于资源的访问工作，将交给User-Agent端完成。这种方式，会将Client端的信息，泄漏给user-Agent端。
如果只使用浏览器（User-Agent和Client都是浏览器），那么User-Agent相当于是登录页面，Client相当于是目标页面。这样做，在单一平台下面是可用的，不能够支持账号的跨平台调用。

密码模式

密码模式也是比较常用到的一种，客户端向授权服务器提供用户名、密码然后得到授权令牌。不过这种模式有种弊端，我们的客户端可以存储用户输入的密码，对于单一平台的用户来说，当然是没有问题的。但是在多个平台之间使用的话，有密码泄漏的风险。流程如下图所示：

这是用户授权最简单，最经典的应用场景。不能做到，账号的跨平台授权和使用。

客户端模式

客户端模式是客户端以自己的名义去授权服务器申请授权令牌，并不是完全意义上的授权。如下图所示：

就好比windows正版软件，有了客户端名称和客户端密码，就可以一直能够通过认证，获取用户权限。

参考文献

1.理解OAuth 2.0
2.oauth2四种授权模式认证流程