Oauth2.0授权方式

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)

授权码模式

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

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

简化模式

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

客户端Client对于资源的访问工作，将交给User-Agent端完成。这种方式，会将Client端的信息，泄漏给user-Agent端。

密码模式

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

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

客户端模式

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

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