为何须要oAuth

若是你接触网络的时间比较早，你应该能体会到网站注册登陆方式的变化：浏览器

早期须要你输入用户名，密码，而后要输入邮箱，基于邮件来完成注册验证，而后使用用户名密码来登陆。由于当时邮箱是相对比较普及的。我当时在大学里学习计算机，老师布置的第一个任务就是去注册个邮箱。
后来手机普及了，网站注册登陆的方式是输入手机号，收到验证码来验证注册登陆
再后来，能够直接基于微信、微博、QQ三方受权的方式来进行登陆

你会发现，注册登陆的方式愈来愈简单：安全

在早期你必须在每一个你须要登录的网站来注册帐号密码，相同的帐号密码吧，怕被盗了一个密码，其它所有被盗。不一样的帐号密码吧，记起来又费劲。后来出现了专门帮人管理密码的软件，不记得叫什么了。
使用手机号码的方式，你能够基于验证码来进行临时登陆，不过每次输入验证码也挺麻烦的
三方受权的方式（也就是oAuth）只须要点击肯定受权，便可以登陆访问，免去了注册、验证、再登录的麻烦

能够看出，如今微信、微博、QQ这些用户基数大的软件，替代了当初的邮箱、手机，变成了注册登陆的基础设施。并且更加的安全：服务器

经过邮箱注册，假设你访问了一些不正经的网站，邮箱被泄露后，会收到一堆垃圾邮件
经过手机号注册，手机号被泄露后，会收到一堆的骚扰电话
而oAuth不会存在泄露的问题，除非微信、微博、QQ泄露了你的信息！

同时你也不须要记一堆乱七八糟的密码了，只须要记着微信、微博、QQ的帐号密码就能够了。微信

另外一方面，对开发者来讲，也省去了对帐号体系的管理，只须要遵循oAuth规范来接入微信、微博、QQ便可，下降了开发成本。markdown

了解了oAuth的做用，咱们来看一看oAuth的实现。网络

oAuth的概念

前段时间阅文集团合同事件闹得沸沸扬扬，其中一个主要的问题就是资源所属问题，合同里规定做者写的做品归阅文集团全部！网友立马就炸了，那做品到底归做者全部仍是阅文集团全部呢？oAuth协议里已经给出了答案。app

oAuth定义了四个角色：oop

资源拥有者（resource owner）：绝大部分状况下，指的是用户。学习
资源服务器（resource server）：指的是服务提供商用来提供服务的服务器。网站
客户端（client）：即三方应用，须要用户来受权访问的应用
受权服务器（authorization server）：即服务提供商专门用来处理受权认证的服务器。

OAuth 2.0的运行流程以下图：

假设咱们要经过阅文来登陆一个第三方网站：

「资源拥有者」打开「网站」之后，该「网站」要求「资源拥有者」给予受权
「资源拥有者」赞成「网站」受权，「网站」接收到受权凭证。这里的受权方式取决于「网站」请求方式以及「受权服务器」所支持的方式。oAuth2.0协议里定义了四种方式，包括：受权码模式、简化模式、密码模式和客户端模式，后面会具体说明。固然也能够自定义。
「网站」使用上一步得到的受权，向「认证服务器」申请令牌
「认证服务器」对「网站」进行认证之后，确认无误，赞成发放令牌
「网站」使用令牌，向「资源服务器」申请获取资源
「资源服务器」确认令牌无误，赞成向「网站」开放资源

流程里很明显：

「网站」就是Client
「认证服务器」就是AuthorizationServer，属于阅文
「资源服务器」就是ResourceServer，也属于阅文
而「资源拥有者」指的就是用户。你用阅文集团来替换「资源拥有者」，就会发现流程明显有问题。

从上面的流程能够看出，整个流程中「三方网站」没有获取到用户的任何敏感信息，且获取的信息须要用户主动受权后才能获取到，保证了安全性和便利性。

oAuth的分类

下面来一个个的说明具体的受权模式。在开始以前，须要多理解几个概念：

User-Agent：用户代理，绝大部分状况下能够直接理解为浏览器
Web Hosted Client Resource：网络托管的客户端资源，这里能够理解为托管网络脚本的服务器

受权码模式（Authorization Code Grant）

受权码模式是功能最完整、流程最严密的受权模式。它经过Client的后台服务器，与「服务提供商」的认证服务器进行互动置换token。具体流程以下：

「用户」基于浏览器访问「客户端」，「客户端」重定向到「认证服务器」对应页面，引导的参数上会附带一个「重定向URI」，指向的是「客户端」页
「用户」选择是否受权
受权后，「认证服务器」根据「重定向URI」将浏览器引导回「客户端」页，同时会附带一个受权码
「客户端」接收到受权码后，经过后台服务器，携带这个受权码以及「重定向URL」，向「认证服务器」申请令牌
「认证服务器」校验无误后，向「客户端」发送令牌（AccessToken）和更新令牌（RefreshToken）

更新令牌(RefreshToken)的做用下文说明

简化模式（Implicit Grant）

简化模式不经过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"受权码"这个步骤。全部步骤在浏览器中完成，令牌对用户是可见的，且客户端不须要认证。具体流程以下：

「用户」基于浏览器访问「客户端」，「客户端」重定向到「认证服务器」对应页面，引导的参数上会附带一个「重定向URI」，指向的是「客户端」页
「用户」选择是否受权
受权后，「认证服务器」根据「重定向URI」将浏览器引导回「客户端」页，在URI的Fragment中会附带访问令牌
「客户端」浏览器根据指令向「Web Hosted Client Resource」发送请求，该请求不包括上一步收到的Fragment，浏览器本地保存Fragment
「Web Hosted Client Resource」返回一个网页（一般是一个包含脚本的网页，若是你理解JSONP，应该比较容易理解），这段脚本是能够从Fragment中解析出访问令牌的
浏览器执行脚本获取令牌
浏览器将令牌发放给客户端

密码模式（Resource Owner Password Credentials Grant）

相对于上面两种受权模式，密码模式相对的不安全，由于用户须要向客户端提供本身的用户名和密码。客户端使用这些信息，向"服务商提供商"索要受权。虽然协议里规定客户端不能存储帐号密码，不过除非你很是信任客户端，不然应该不会使用这种模式。

这种受权模式的具体流程以下：

「用户」向「客户端」提供用户名和密码
「客户端」将用户名和密码发送给「认证服务器」，请求令牌
「认证服务器」验证后，返回访问令牌

客户端模式（Client Credentials Grant）

客户端模式下，用户直接向客户端注册，客户端以本身的名义要求"服务提供商"提供服务。具体流程以下：

「客户端」向「认证服务器」进行身份认证，并要求一个访问令牌
「认证服务器」验证后，返回访问令牌

更新令牌

在上面的流程中，认证服务器认证后返回的数据，除了访问令牌，还有一个更新令牌。咱们知道了，经过访问令牌咱们才可以访问资源，那更新令牌是作什么用的呢？

咱们都知道，通常网站登陆会有一个超时时间，这里也不例外。访问令牌也有一个超时时间。更新令牌就是用于在访问令牌过时后来获取新的访问令牌的。

「客户端」向「受权服务器」进行认证，获取access token。
「受权服务器」验证「客户端」后，发放访问令牌和刷新令牌。
「客户端」携带访问令牌向「资源服务器」请求资源
「资源服务器」验证访问令牌，若是有效，则提供服务。
重复步骤3和4直到访问令牌到期
当访问令牌无效，「资源服务器」返回无效的令牌错误
「客户端」向受权服务器进行身份验证，并携带刷新令牌来请求新的访问令牌
「受权服务器」验证「客户端」身份以及刷新令牌，若是有效，则发出新的访问令牌（以及可选的新刷新令牌）

最后补充

在上面的流程中，实际还缺乏了一步，就是注册客户端。若是你接过微信、微博或QQ的受权登录，那么应该清楚，在开始接入以前，咱们须要在他们的开放平台上申请咱们的应用，申请成功后会给咱们一个appId和一个appSecrect。

这个的appId就是用来惟一肯定客户端的。而appSecrect就是在受权模式中，客户端的后台与受权服务器交互时须要连同code，appId一块儿提供的，用于置换访问令牌的。

总结

本文解释了oAuth的做用，并梳理了oAuth的具体流程。

参考文档

《The OAuth 2.0 Authorization Framework》www.ietf.org/rfc/rfc6749…

公号：抽象思惟

基于oAuth的受权登陆