一、简介
资源所有者为了给第三方应用提供受限资源的访问权限，需要与第三方共享它的凭据。
作为使用资源所有者的凭据访问受保护资源的替代，客户端获得一个访问令牌———一个代表特定作用域、生命周期以及其他访问权限属性的字符串。访问令牌由授权服务器在资源所有者认可的情况下颁发给第三方客户端。客户端使用访问令牌访问托管在资源服务器上的受保护资源。
使用HTTP（RFC2616）协议设计。
1、角色
OAuth定义了四种角色：
资源所有者
能够许可对受保护资源的访问权限的实体。当资源所有者是个人时，它被称为最终用户。
资源服务器
托管受保护资源的服务器，能够接收和响应使用访问令牌对受保护资源的请求。
客户端
使用资源所有者的授权代表资源所有者发起对受保护资源的请求的应用程序。术语“客户端”并非特指任何特定的的实现特点（例如：应用程序是否是在服务器、台式机或其他设备上执行）。
授权服务器
在成功验证资源所有者且获得授权后颁发访问令牌给客户端的服务器。
授权服务器可以和资源服务器是同一台服务器，也可以是分离的个体。一个授权服务器可以颁发被多个资源服务器接受的访问令牌。（当然这些东西可以是同一台服务器上的同一个程序也可以是同一台服务器上的两个程序等等，个人理解为四种角色是逻辑上的定义和划分。）
2、协议流程
+--------+ +---------------+ | |--(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 ---| | +--------+ +---------------+
- （A）客户端从资源所有者处请求授权。授权请求可以直接向资源所有者发起（如图所示），或者更可取的是通过授权服务器作为中介间接发起。
- （B）客户端收到授权许可，这是一个代表资源所有者的授权的凭据，使用规范中定义的四种许可（授权码、隐式授权、资源所有者密码凭证、客户端凭证）类型之一或者使用扩展许可类型表示。授权许可类型取决于客户端请求授权所使用的方法以及授权服务器支持的类型。
- （C）客户端与授权服务器进行身份认证并出示授权许可以请求访问令牌。
- （D）授权服务器验证客户端身份并验证授权许可，若有效则颁发访问令牌。
- （E）客户端从资源服务器请求受保护资源并出示访问令牌进行身份验证。
- （F）资源服务器验证访问令牌，若有效则处理该请求。
客户端从资源所有者获得授权许可（步骤（A）和（B）所示）的更好方法是使用授权服务器作为中介（仅供参考，后面会有）
3、授权方式
①授权码
授权码通过使用授权服务器做为客户端与资源所有者的中介而获得。客户端不是直接从资源所有者请求授权，而是引导资源所有者至授权服务器（由在RFC2616中定义的用户代理），授权服务器之后引导资源所有者带着授权码回到客户端。
在引导资源所有者携带授权码返回客户端前，授权服务器会鉴定资源所有者身份并获得其授权。由于资源所有者只与授权服务器进行身份验证，所以资源所有者的凭据不需要与客户端分享。
授权码提供了一些重要的安全益处，例如验证客户端身份的能力，以及向客户端直接的访问令牌的传输而非通过资源所有者的用户代理来传送它而潜在暴露给他人（包括资源所有者）。
注：授权码的这个东西说的可能有点绕了，仔细阅读两三遍后，如果还是没能理解的话先放下，后面还有更详细的部分。算了，直接把后面的拿过来把，帮助下理解。
授权码许可
授权码许可类型用于获得访问令牌和刷新令牌并且为受信任的客户端进行了优化。由于这是一个基于重定向的流程，客户端必须能够与资源所有者的用户代理（通常是Web浏览器）进行交互并能够接收来自授权服务器的传入请求（通过重定向）。
+----------+
| 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)
注：说明步骤（A）、（B）和（C）的直线因为通过用户代理而被分为两部分。
（A）客户端通过向授权端点引导资源所有者的用户代理开始流程。客户端包括它的客户端标识、请求范围、本地状态和重定向URI，一旦访问被许可（或拒绝）授权服务器将传送用户代理回到该URI。
（B）授权服务器验证资源拥有者的身份（通过用户代理），并确定资源所有者是否授予或拒绝客户端的访问请求。
（C）假设资源所有者许可访问，授权服务器使用之前（在请求时或客户端注册时）提供的重定向URI重定向用户代理回到客户端。重定向URI包括授权码和之前客户端提供的任何本地状态。
（D）客户端通过包含上一步中收到的授权码从授权服务器的令牌端点请求访问令牌。当发起请求时，客户端与授权服务器进行身份验证。客户端包含用于获得授权码的重定向URI来用于验证。
（E）授权服务器对客户端进行身份验证，验证授权代码，并确保接收的重定向URI与在步骤（C）中用于重定向（资源所有者的用户代理）到客户端的URI相匹配。如果通过，授权服务器响应返回访问令牌与可选的刷新令牌。
麻蛋，这流程有点绕啊，不知道有没有做微信公众号的基础，微信公众号开发时，需要获取用户信息，使用的验证方式就是这种方式，为了方便理解，我找找微信公众号的开发文档，拿出来看看，方便理解。
2 第二步：通过code换取网页授权access_token
4 第四步：拉取用户信息(需scope为 snsapi_userinfo)
这是微信开发获取用户信息的一个流程
其中，第一步是对应的ABC的流程，第二、三步对应的则是DE的流程。
其中Client指代第三方的应用，需要获取微信用户信息的应用；UserAgent所谓的用户代理指代微信用户端或浏览器等；ResourceOwner指代的是用户本身，也就是微信信息的所有者；AuthoriztionServer就是微信的鉴权的服务器了。
A.用户向微信客户端（受信任的用户代理）申请鉴权，微信将请求转发给微信的鉴权服务器，返回用户确认的界面；
B.微信客户端向用户确认是否授予第三方请求的权限，然后将确认的结果返回给微信的鉴权服务器
C.鉴权服务器根据微信客户端（这是个受信任的用户代理）的授权结果，返回相应的信息；如果用户授予权限，则返回给微信客户端授权码；微信客户端将授权码返回给第三方的回调接口，完成鉴权过程的第一部分。
剩下的就好说了，第三方用获取到的这个授权码，即可去鉴权服务器换取可以访问资源的通行证Token。
详细说明：
②隐式授权
隐式许可是为用如JavaScript等脚本语言在浏览器中实现的客户端而优化的一种简化的授权码流程。在隐式许可流程中，不再给客户端颁发授权码，取而代之的是客户端直接被颁发一个访问令牌（作为资源所有者的授权）。隐式许可提高了一些客户端（例如一个作为浏览器内应用实现的客户端）的响应速度和效率，因为它减少了获取访问令牌所需的往返数量。然而，这种便利应该和采用隐式许可的安全影响作权衡。
或许，我理解加密狗应该就属于这种隐式授权的范畴吧。
③资源所有者密码凭据
这个应该比较好理解，通过用户名、密码的方式直接到鉴权服务器换取Token。
④客户端凭据
直接对客户端进行标记，具有该标记的客户端可直接到鉴权服务器获取Token。
为啥我觉得加密狗也可以算在这一类型当中呢。。。
麻蛋，我是不是智障了。
--------------------------------------------------------------------------------------------
目前先了解这么多把，对于OAuth2.0目前先接触这些。
https://github.com/jeansfish/RFC6749.zh-cn/blob/master/SUMMARY.md