OAuth 2.0

标准文档（英文）https://tools.ietf.org/html/rfc6749 

是什么

OAuth 2.0 授权框架使得第三方可以获取对用户资源的访问（有限访问或者完全访问）。

举个例子：通过你的允许，bilibili 可以去微信服务器获取你的头像，昵称，openid 等等。

实际项目中：可以通过获取access_token访问能开系统中的数据，比如接口调用。

为什么

传统授权方式，用户和第三方共享密码。缺点如下：

1. 未来可能持续需要访问各种受限资源。所以第三方要存储用户密码，一般情况密码是明文，显然不安全。
2. 第三方将可以访问所有的资源，而实际上它只应当有权限访问部分资源。
3. 用户不能撤销单个第三方的访问权限。改密码，所有第三方都会失效。

核心

 OAuth 2.0 的核心思想是向第三方应用程序颁发访问令牌。

术语（四个角色）

案例：用户通过“微信登陆”登陆 bilibili 。

专业称呼	通俗叫法
资源所有者	用户
资源服务器	保存用户信息的服务器并且能够验证令牌是否合法（比如说，微信服务器、B站服务器、QQ服务器、淘宝服务器等，保存你的用户数据等）
客户端	第三方应用程序（比如说，微信、bilibili等）
授权服务器	发送令牌给第三方的服务器（可以和资源服务器是同一个）

协议流程 

抽象协议流程图解释

（A）客户端请求资源所有者的授权。授权请求可以直接向资源所有者提出，或者最好间接通过授权服务器作为中介。
（B）客户端收到授予的授权，即代表资源所有者授权的凭证。使用下面定义的四种授予类型之一表示指定或者使用扩展授权类型。这个授权授予类型取决于请求授权的客户端和授权服务器。
（C）客户端通过使用资源所有者授予的授权（Code）向授权服务器申请访问令牌（access_token）。
（D）授权服务器验证客户端身份与资源所有者授予的授权，如果有效，则颁发访问令牌。
（E） 客户端通过提供访问令牌进行身份验证去资源服务器请求受保护的资源。
（F）资源服务器验证访问令牌，如果有效，则满足客户端的服务请求。

授权方法

OAuth 2.0 提供了四种授予客户端访问令牌的方法：

• 授权码模式（适用前后端分离）
• 隐藏式
• 密码式
• 客户端凭证

授权码模式（适用前后端分离）

最常用的模式，微信、QQ、Github 登陆第三方网站就是这种模式。优点前后端分离，避免令牌泄露。

1. 哔哩哔哩提供一个“微信登陆”的链接，用户点击跳转到微信授权服务器。
2. 用户根据微信授权服务器提示登陆微信并确认授权给哔哩哔哩。
3. 微信授权服务器返回用户代理（浏览器）一个授权码。
4. 用户代理（浏览器）把这个授权码传给哔哩哔哩。
5. 哔哩哔哩凭借授权码向微信授权服务器请求令牌。
6. 微信授权服务器发送令牌给哔哩哔哩。

之后哔哩哔哩就可以带着令牌去微信资源服务器读取用户资料。 

隐式模式（不推荐使用）（适合没有后台的第三方）

1. 哔哩哔哩提供一个“微信登陆”的链接，用户点击跳转到微信授权服务器。
2. 用户根据微信授权服务器提示登陆微信并确认授权给哔哩哔哩。
3. 微信授权服务器发送令牌给哔哩哔哩。

https://weixin.com/oauth/authorize?
  response_type=token&
  client_id=123&
  redirect_uri=http://www.bilibili.com/callback&
  scope=read

密码模式（适合用户极其信任第三方）

1. 哔哩哔哩使用用户给的微信登陆账号和密码直接向微信授权服务器索要令牌。
2. 微信授权服务器发送令牌给哔哩哔哩。

https://weixin.com/token? 
    grant_type=password& 
    username=张三& 
    password=123456& 
    client_id=123

客户端模式（适合没有前端的第三方，整个过程没有用户参与）

1. 哔哩哔哩向微信授权服务器请求令牌。
2. 微信授权服务器发送令牌给哔哩哔哩。

https://weixin.com/token?
  grant_type=client_credentials&
  client_id=123&
  client_secret=xxxxx