基于oAuth的授权登陆 _oAuth

为什么需要oAuth如果你接触网络的时间比较早，你应该能体会到网站注册登录方式的变化：

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

你会发现，注册登录的方式越来越简单：

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

可以看出，现在微信、微博、QQ这些用户基数大的软件，替代了当初的邮箱、手机，变成了注册登录的基础设施。而且更加的安全：

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

同时你也不需要记一堆乱七八糟的密码了，只需要记着微信、微博、QQ的账号密码就可以了。
另一方面，对开发者来说，也省去了对账号体系的管理，只需要遵循oAuth规范来接入微信、微博、QQ即可，降低了开发成本。
了解了oAuth的作用，我们来看一看oAuth的实现。
oAuth的概念前段时间阅文集团合同事件闹得沸沸扬扬，其中一个主要的问题就是资源所属问题，合同里规定作者写的作品归阅文集团所有！网友立马就炸了，那作品到底归作者所有还是阅文集团所有呢？oAuth协议里已经给出了答案。
oAuth定义了四个角色：

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

OAuth 2.0的运行流程如下图：

文章插图

假设我们要通过阅文来登录一个第三方网站：

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

流程里很明显：