之前文章都是讲解的用户名或者短信登录认证的方式，这节开始学习第三方授权认证的登录方式，在学习授权登录之前就不得不先学习OAuth2.0协议的相关知识，一起来看看吧！
什么是OAuth2.0?
百科解读
- OAuth（开放授权）是一个
开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。OAuth2.0是OAuth协议的延续版本，但不向前兼容OAuth 1.0，即完全废止了OAuth1.0。
应用场景
- 第三方应用授权登录：在APP或者网页接入一些第三方应用时，很多时候会有一些
授权登录按钮，比如QQ，微博，微信的授权登录。 - 原生app授权：app登录请求后台接口，为了安全认证，所有请求都带
Token信息，再进行登录验证、请求后台数据。 - 前后端分离单页面应用：前后端分离框架，前端请求后台数据，需要
进行OAuth2.0安全认证，比如使用vue、react或者H5开发的应用，比如小程序等。
OAuth协议中的各种角色及职责
- 服务提供商（Provider）：
提供授权许可、访问令牌等。 - 资源所有者（Resource Owner）：用户名、昵称、头像
信息的所有者，即用户，可以同意或者拒绝授权。 - 第三方应用（Client）：
比如说博客，它要把微信的用户变成自己的用户，就需要微信授权给博客。 - 认证服务器（Authorization Server）：属于服务提供商，主要责任是
认证用户身份，并且产生令牌。 - 资源服务器（Resource Server）：资源服务器，作用一个是
保存用户资源，比如上面的用户信息，另一个是验证令牌的有效性。
OAuth协议流程
- 流程图解
- 流程说明：
首先用户访问第三方应用，应用会请求用户是否授权，用户同意授权之后，第三方应用就会去访问服务提供商的认证服务器，并且告诉它用户同意我访问你的资源数据，请给我一个令牌，认证服务器会验证第三方应用说的是不是实话，用户是不是真的同意第三方访问，如果确实同意，认证服务器就会发放令牌给第三方应用，第三方应用拿到令牌之后就可以使用令牌向资源服务器去申请获取资源，资源服务器会验证令牌的有效性，确认无误之后就会把资源开放给第三方应用。在不同的场景，OAuth协议一共定义了四种授权模式，如下文。
OAuth2.0的四种授权模式
授权码模式（authorization code）
- 说明：授权码模式是四种模式中
功能最完整，流程最严密的授权模式，互联网上能看到的所有的提供商，微博、微信、QQ、百度等都采用的是授权码模式来完成OAuth流程的。 - 流程图解
- 流程说明：
首先用户访问客户端，如果第三方应用需要用户授权，就会将用户导向认证服务器，用户同意授权的动作会在认证服务器完成，如果用户同意授权会将用户重新导回到第三方应用上去，同时携带授权码（注意这里并不是令牌），导回到哪个地址是第三方应用和认证服务器商量好的，第三方应用收到授权码以后会拿着授权码向认证服务器去申请令牌，这一步是在客户端服务器完成的对用户是不可见，然后认证服务器会核对发过来的授权码是不是之前第三步发过去的授权码，确认无误之后就会向客户端发送最终的访问令牌，即Token。这就是授权码模式的主要流程。 - 特点一：和其他三种模式不同的是，
用户同意授权的动作是在认证服务器上完成的，其他模式都是在第三方应用上完成的，完成以后第三方应用带着一些信息跟认证服务器说用户授权给我了，同意我访问，这时候认证服务器是没法确定用户是否真的授权，有可能这个授权信息是第三方应用伪造的；而在授权码模式里，同意授权这个动作是在认证服务器上完成的，所以他明确知道用户确实同意了授权。 - 特点二：用户同意授权之后，返回给第三方的
并不是最终的令牌，而是一个授权码，第三方应用接到授权码以后再发一个请求给认证服务器，拿授权码去换真正的令牌。
简化模式（implicit）
- 有些第三方网站没有专门的服务器，这种时候就可以用简化模式，就是
从认证服务器返回到第三方应用的时候直接带的就是令牌，不支持刷新令牌，令牌容易因为被拦截窃听而泄露，所以安全性上授权码模式是更高的。
密码模式（resource owner password credentials）
- 用户向客户端提供用户名密码，
使用用户名、密码作为授权方式发给认证服务器请求令牌，认证服务器确认无误后，向客户端提供访问令牌，一般不支持刷新令牌。
客户端模式（client credentials）
- 客户端向认证服务器
进行身份认证，并请求一个访问令牌，认证服务器确认无误后，向客户端提供访问令牌。