什么是OAuth2.0
１．用于rest/api的代理请求框架。
２．解耦认证和授权
３．基于令牌Token的授权，在无需暴露用户密码的情况下，让应用能获得对用户数据的访问权限。
４．事实上的标准安全框架，支持多种用例场景。适用于，服务端webapp,单页spa,原生app，服务器服务器之间。
OAuth2.0的优势
１．易于实现。
２．更加安全，客户端不接触密码，服务端集中保护。本质上就是解决这个问题。
３．广泛传播并持续采用。
４．短寿命和封装的token。
５. 资源服务器和授权服务器解耦。一个负责授予token权限(客户端访问其，其返回页面给用户，判断是否同意授权，同意，则授予让其有资格访问我的数据)，一个负责判断请求是否具有token
６．集中授权
７．基于http/json，易于请求和传递token
８．考虑了多种客户端场景
９．客户端有多种信任级别。
OAuth2.0的不足
１.协议太宽泛了，因此各个实现版本兼容性不好。
２．和Oauth1.0不兼容。
３．Oauth2.0不是一个认证协议，他是个授权框架，他本省不会告诉你任何用户信息。是个授权协议。
Oauth2.0主要角色术语
１．资源拥有者：资源的拥有者，用户。
２．客户应用：通常是一个web应用，想要访问收到保护的数据。比如微信用户数据等。
３．资源服务器：一个web站点或者service api,客户想要访问的数据在我这里。
４．授权服务器：客户想要访问受保护的数据，必须先到我这里来认证，来获取到access token。
５．客户凭证：在授权服务器上注册后获得的，客户的ClientId和密码用于认证客户。
６．令牌：授权服务器接受到客户端请求后，验证后颁发的访问令牌
７．作用域：客户请求访问令牌是，由资源额外指定的细分权限。
Oauth2.0 令牌类型
１．access token：访问令牌用来代表一个用户或者服务直接去访问受保护的资源。
２．refresh token:刷新令牌，勇于去授权服务器获取一个新的令牌。（有时候访问令牌过期了，有的流程会支持获取到一个refreshtoken,我可以通过这个换取一个新的令牌）
３．Bearer Token：不管谁拿到token,都可以访问资源。
４．pop token:可以校验client是否对token的用友权。
５．Authorization Code Token:授权码，仅用于授权码授权类型。用于交换获取访问令牌和刷新令牌。
Ouath2.0的误区
１．该协议仅仅支持http协议。
２．Oauth 是个授权协议，不是认证协议。
３．oauth 没有定义token格式
４．没有定义加密算法
５．不是单个协议
６．没有定义授权处理机制
７．仅仅是个授权框架，用于授权代理
授权模式
授权码模式
用下面转载自码农翻身的一张图来解释下
１．用户访问客户端，客户端将用户重定向到授权服务器。同时附上客户端凭证和处理完后要重定向的url。
２．用户选择是否给予客户端授权。
３．用户给予授权，授权服务器将用户导向客户端事先指定的”重定向URI”（redirection URI），同时附上一个授权码。
４．客户端收到授权码，附上早先的”重定向URI”，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。
５．认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。
简化模式
（A）客户端将用户导向认证服务器。
（B）用户决定是否给于客户端授权。
（C）假设用户给予授权，认证服务器将用户导向客户端指定的”重定向URI”，并在URI的Hash部分包含了访问令牌。
（D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。
（E）资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。
（F）浏览器执行上一步获得的脚本，提取出令牌。
（G）浏览器将令牌发给客户端。
密码模式
这个通常需要客户端是操作系统的一部分，或者是一个著名公司出品，而认证服务器无法授权处理才使用。
（A）用户向客户端提供用户名和密码。
（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。
（C）认证服务器确认无误后，向客户端提供访问令牌。
客户端模式
其实不存在授权问题，客户端自己向授权服务器拿令牌。
（A）客户端向认证服务器进行身份认证，并要求一个访问令牌。
（B）认证服务器确认无误后，向客户端提供访问令牌。
为何要加个授权码呢？
为了避免把token透露给浏览器，最好是透明的，我们不希望处理到这个token暴露在浏览器里面，每次重定向都会经过浏览器的。因此如果直接返回token的话就会产生问题。因此我们一般使用授权码的方式。