OAuth2机制详解

概述

一看OAuth2这个词，感觉有些许新奇。毕竟每天都在忙着ctrl+c、ctrl+v，哪有闲工夫去了解OAuth2这个看似安全层面的技术，看起来就离平日的开发很遥远。但是稍微静下心来看一看，会发现OAuth2其实应用在很多场景下，我们常常在重复这个行为，却没有意识到这是一个OAuth的标准。

OAuth场景

首先， OAuth是Open Authorization的简写，其本质是一种用于授权的开放协议。百度百科是这样解释的：“OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准”。而OAuth2.0顾名思义，就是OAuth协议的二代版本，按照正常而言，2.0必然比1.0更加强劲更加好用，但它并不向前兼容OAuth 1.0（即完全废止了OAuth1.0），现在大家经常使用的百度、腾讯等开放平台基本上也都是基于OAuth2.0进行开发的，因此本文主要针对OAuth2.0进行阐述。

说了一堆OAuth和OAuth2.0，大家只知道它是一种授权机制，但可能很多人还是不明白OAuth协议是用来干嘛的。简单来说，OAuth就是授权第三方应用，获取用户数据的一个协议。它不会将用户名密码交给第三方应用，而是生成一个临时token用于访问第三方应用的数据。过于抽象？举两个简单的例子。

QQ授权

GitHub授权

以上两个场景应该都很熟悉吧，这就是典型的授权场景。比如使用QQ登录有道云笔记，有道云笔记作为第三方应用想要读取QQ的部分数据，就需要用户对有道云笔记授权，使得有道云笔记能够有权限访问QQ的部分用户数据。给LeetCode授权GitHub权限同理。当然，整个过程不会涉及到用户名密码的传输，如果把用户名密码直接交给第三方应用，那第三方应用就可以为所欲为了。看这两个页面的URL也能感受出来， 这都是典型的OAuth2.0协议场景。

OAuth授权机制

将以上互联网场景映射到现实生活，其实很像“访客码”这个东西。比如你在某单位工作，每栋楼都有门禁，输入用户名和密码即可通行。此时你们的项目有第三方合作伙伴，且第三方合作伙伴需要驻场到B栋楼一段时间，把你的用户名密码直接给他们的话，他们就可以在所有楼栋通行了，并且当合作结束后，你可能还需要将你的用户名密码修改，避免他们再次进入，这种机制显然是不合适的。那么有没有一种办法，能够不把用户名密码给合作伙伴，且将他们的进入权限限制在B栋楼呢？OAuth授权机制就是为解决此类问题而生的。OAuth整个授权机制如下：

1. 门禁系统增加“授权”按钮，当合作伙伴第一次来到B栋楼，首先需要点击这个按钮向单位工作人员申请进入权限；
2. 单位工作人员收到该申请，包括该申请的申请人和楼栋号，同意了该授权申请；
3. 合作伙伴收到短信，包含一个令牌信息（access_token），在某短时间内有效；
4. 合作伙伴在门禁中输入令牌，在有效期内便能够在B栋楼自由出入了。

有人可能会问，为什么不直接生成一个新的用户名密码，供合作伙伴使用？这是因为用户名密码包含所有楼栋的权限，且不会失效，和单位工作人员的权限完全一样。那么为什么不能每次进门都请求开门呢？这是因为单位可能会有多道门禁，频繁地同意授权显然会给单位工作人员造成极大的困扰。而使用一个临时令牌，过期即失效，便能够安全有效地隔离权限，并能够在一定时间后释放它。

令牌与密码的异同

从OAuth机制中可以看到，其本质就是用令牌代替了用户名密码的作用，使得系统可以在不获取用户名密码的前提下访问用户资源，这常见于各大开放平台。但凡你创建的系统中，需要访问其它系统的数据或资源，都需要经历这个请求授权的过程。

虽然令牌和密码的作用都是访问用户资源，但两者还是有很大的区别：

1. 密码一般长期有效，令牌有过期时间；
2. 密码不允许被撤销，而用户一般具有取消授权的能力；
3. 密码一般是所有权限，令牌是部分权限，在授权过程中会对令牌的权限范围进行定义。

以上设计，使得令牌比密码更加灵活、安全，但是令牌的隐私程度并不亚于密码，因此也不应该被泄漏。

总结

本文主要是从原理和机制的角度对OAuth2进行了简单的说明，并没有涉及到系统和代码层面的内容。OAuth2实现方式将从代码流程的角度，详细说明OAuth2的四种实现方式。