1、应用场景
2、角色说明
3、OAuth2.0 概述
4、协议流程
5、四种授权模式
6、授权码模式
应用场景
这里以“简书”为例，网友希望在简书的文章下留言，但需要先登录。在登录页面，提供多种方式登录，例如：微博、微信、QQ账户等。减少了网友注册并管理多个账户的麻烦。但简书如何使用微博登录，获取用户信息并确保其数据不被泄露，这时 OAuth2.0 派上用场。
角色说明
1、Resource Owner
资源拥有者，能够许可对受保护资源的访问权限的实体。当资源所有者是个人时，它被称为最终用户。
2、Resource Server
资源服务器，管理受保护资源的服务器，能够接收和响应使用访问令牌对受保护资源的请求。例如，微博的资源服务器。
3、Client
第三方应用客户端，资源拥有者发起对受保护资源的请求的应用程序。例如：简书。
4、Authorization Server
授权服务器，在成功验证资源拥有者且获得授权后颁发访问令牌给客户端的服务器。例如，微博的授权服务器。
OAuth2.0 概述
OAuth2.0 授权框架允许第三方应用获取对 HTTP 服务的有限的访问权限，既可以以资源所有者名义在资源所有者和 HTTP 服务之间进行允许的交互，也可以允许第三方应用以自己的名义进行访问。本规范取代并淘汰 RFC5849 中描述的 OAuth 1.0 协议。（摘自：https://github.com/jeansfish/RFC6749.zh-cn/blob/master/index.md）
协议流程
OAuth 2.0 的协议流程如下图，摘自 RFC6749。
上图是抽象的 OAuth 2.0 协议流程，描述了四种角色之间的交互，包括以下步骤：
- （A）客户端从资源所有者处请求授权。授权请求可以直接向资源所有者发起，或者更可取的是通过授权服务器作为中介间接发起。
- （B）客户端收到授权许可，这是一个代表资源所有者的授权的凭据，使用本规范中定义的四种许可类型之一或者使用扩展许可类型表示。授权许可类型取决于客户端请求授权所使用的方法以及授权服务器支持的类型。
- （C）客户端与授权服务器进行身份认证并出示授权许可以请求访问令牌。
- （D）授权服务器验证客户端身份并验证授权许可，若有效则颁发访问令牌。
- （E）客户端从资源服务器请求受保护资源并出示访问令牌进行身份验证。
- （F）资源服务器验证访问令牌，若有效则处理该请求。
客户端从资源所有者获得授权许可（步骤（A）和（B）所示）的更好方法是使用授权服务器作为中介，也就是授权码模式。
四种授权模式
客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0定义了四种授权方式。
- 授权码模式（authorization code）
- 简化模式（implicit）
- 密码模式（resource owner password credentials）
- 客户端模式（client credentials）
授权码模式
授权码许可类型用于获得访问令牌和刷新令牌并且为受信任的客户端进行了优化。由于这是一个基于重定向的流程，客户端必须能够与资源所有者的用户代理（通常是Web浏览器）进行交互并能够接收来自授权服务器的传入请求（通过重定向）。
注：说明步骤（A）、（B）和（C）的直线因为通过用户代理而被分为两部分。
上图描述了授权码流程，包括以下步骤：
- （A）客户端通过向授权端点引导资源所有者的用户代理开始流程。客户端包括它的客户端标识、请求范围、本地状态和重定向URI，一旦访问被许可（或拒绝）授权服务器将传送用户代理回到该URI。
- （B）授权服务器验证资源拥有者的身份（通过用户代理），并确定资源所有者是否授予或拒绝客户端的访问请求。
- （C）假设资源所有者许可访问，授权服务器使用之前（在请求时或客户端注册时）提供的重定向URI重定向用户代理回到客户端。重定向URI包括授权码和之前客户端提供的任何本地状态。
- （D）客户端通过包含上一步中收到的授权码从授权服务器的令牌端点请求访问令牌。当发起请求时，客户端与授权服务器进行身份验证。客户端包含用于获得授权码的重定向URI来用于验证。
- （E）授权服务器对客户端进行身份验证，验证授权代码，并确保接收的重定向URI与在步骤（C）中用于重定向（资源所有者的用户代理）到客户端的URI相匹配。如果通过，授权服务器响应返回访问令牌与可选的刷新令牌。
注：上述的应用场景使用了此模式，将在下一篇以示例说明。