概述
OAuth 2.0 是一个行业的标准授权协议。OAuth 2.0 专注于简化客户端开发人员，同时为 Web 应用程序，桌面应用程序，手机和客厅设备提供特定的授权流程。
它的最终目的是为第三方应用颁发一个有时效性的令牌 token。使得第三方应用能够通过该令牌获取相关的资源。常见的场景就是：第三方登录。当你想要登录某个论坛，但没有账号，而这个论坛接入了如 QQ、Facebook 等登录功能，在你使用 QQ 登录的过程中就使用的 OAuth 2.0 协议。
角色
授权协议的流程围绕一些角色展开。
- 资源拥有者(Resource Owner)，即用户，指能够允许访问受保护资源的实体，拥有资源的所有权。如果是个人，被称为end-user。
- 资源服务器(Resource Server)，保存资源拥有者的数据(资源)的服务器。
- 客户端(Client)，使用资源所有者的授权，代表资源所有者发起对受保护资源的请求的应用程序，可以是APP、网页、第三方系统等。
- 授权服务器(Authorization Server)，第三方搭建用于接收资源拥有者(用户)授权的服务器，在获取用户的同意授权后，能够向客户端颁发访问令牌(Access Token)，以便客户端获取用户资源。
- 用户代理(User-agent)，帮助资源所有者与客户端沟通的工具。
OAuth 2.0标准化了访问令牌的请求与响应部分。Oauth 2.0的细节在RFC 6749中有详细定义。
协议流程
- 客户端请求资源拥有者的授权。
- 客户端获得授权许可。
- 客户端向授权服务器请求访问令牌。
- 授权服务器验证客户端的授权许可，有效则颁发允许访问资源服务器的令牌，令牌具有时效性。
- 客户端通过访问令牌向资源服务器请求受保护的资源。
- 资源服务器验证客户端的访问令牌，访问令牌有效则响应请求。
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Figure 1: Abstract Protocol Flow
授权
客户端需要提供重定向 URI用于在用户授权（或拒绝）应用程序之后重定向用户的地址。
授权类型
OAuth 2.0 提供了四种不同场景下的授权类型。这里我们主要介绍授权码类型(Authorization Code)
授权码模式
授权码模式主要用于第三方登录。
- 资源拥有者(用户)选择第三方登录客户端(网页、APP等)。
- 客户端重定向到第三方的授权服务器。时客户端携带了客户端标识（client_id），那么第三方就知道这是哪个客户端，资源拥有者确定/拒绝授权后需要重定向到哪里。
- 用户确认授权，客户端被重定向到注册时给定的 URI，并携带了第三方给定的 code。
- 在重定向的过程中，客户端拿到 code 与 client_id、client_secret 去授权服务器请求令牌，如果成功，直接请求资源服务器获取资源，整个过程，用户代理是不会拿到令牌 token 的。
- 客户端（APP）拿到令牌 token 后就可以向第三方的资源服务器请求资源了。
+----------+
| Resource |
| Owner |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
Note: The lines illustrating steps (A), (B), and (C) are broken into
two parts as they pass through the user-agent.
Figure 3: Authorization Code Flow
