OAuth 2.0 是目前最流行的授权机制，用来授权第三方应用，获取用户数据。
这个标准比较抽象，使用了很多术语，初学者不容易理解。其实说起来并不复杂，下面我就通过一个简单的类比，帮助大家轻松理解，OAuth 2.0 到底是什么。
一、快递员问题
我住在一个大型的居民小区。
小区有门禁系统。
进入的时候需要输入密码。
我经常网购和外卖，每天都有快递员来送货。我必须找到一个办法，让快递员通过门禁系统，进入小区。
如果我把自己的密码，告诉快递员，他就拥有了与我同样的权限，这样好像不太合适。万一我想取消他进入小区的权力，也很麻烦，我自己的密码也得跟着改了，还得通知其他的快递员。
有没有一种办法，让快递员能够自由进入小区，又不必知道小区居民的密码，而且他的唯一权限就是送货，其他需要密码的场合，他都没有权限？
二、授权机制的设计
于是，我设计了一套授权机制。
第一步，门禁系统的密码输入器下面，增加一个按钮，叫做"获取授权"。快递员需要首先按这个按钮，去申请授权。
第二步，他按下按钮以后，屋主（也就是我）的手机就会跳出对话框：有人正在要求授权。系统还会显示该快递员的姓名、工号和所属的快递公司。
我确认请求属实，就点击按钮，告诉门禁系统，我同意给予他进入小区的授权。
第三步，门禁系统得到我的确认以后，向快递员显示一个进入小区的令牌（access token）。令牌就是类似密码的一串数字，只在短期内（比如七天）有效。
第四步，快递员向门禁系统输入令牌，进入小区。
有人可能会问，为什么不是远程为快递员开门，而要为他单独生成一个令牌？这是因为快递员可能每天都会来送货，第二天他还可以复用这个令牌。另外，有的小区有多重门禁，快递员可以使用同一个令牌通过它们。
三、互联网场景
我们把上面的例子搬到互联网，就是 OAuth 的设计了。
首先，居民小区就是储存用户数据的网络服务。比如，微信储存了我的好友信息，获取这些信息，就必须经过微信的"门禁系统"。
其次，快递员（或者说快递公司）就是第三方应用，想要穿过门禁系统，进入小区。
最后，我就是用户本人，同意授权第三方应用进入小区，获取我的数据。
简单说，OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。
四、令牌与密码
令牌（token）与密码（password）的作用是一样的，都可以进入系统，但是有三点差异。
（1）令牌是短期的，到期会自动失效，用户自己无法修改。密码一般长期有效，用户不修改，就不会发生变化。
（2）令牌可以被数据所有者撤销，会立即失效。以上例而言，屋主可以随时取消快递员的令牌。密码一般不允许被他人撤销。
（3）令牌有权限范围（scope），比如只能进小区的二号门。对于网络服务来说，只读令牌就比读写令牌更安全。密码一般是完整权限。
上面这些设计，保证了令牌既可以让第三方应用获得权限，同时又随时可控，不会危及系统安全。这就是 OAuth 2.0 的优点。
注意，只要知道了令牌，就能进入系统。系统一般不会再次确认身份，所以令牌必须保密，泄漏令牌与泄漏密码的后果是一样的。 这也是为什么令牌的有效期，一般都设置得很短的原因。
OAuth 2.0 对于如何颁发令牌的细节，规定得非常详细。具体来说，一共分成四种授权类型（authorization grant），即四种颁发令牌的方式，适用于不同的互联网场景。下一篇文章，我就来介绍这四种类型，并给出代码实例。
（完）
庆南 说：
期待下集
2019年4月 4日 08:57 | # | 引用
bbb 说：
不错，写的很清楚了。
2019年4月 4日 09:10 | # | 引用
凌晨的蝌蚪 说：
刚好在看OAuth2.0，阮老师就出教程 感谢
2019年4月 4日 09:17 | # | 引用
tiger 说：
到不是不好理解，而是安全性问题，一直觉得这样很不安全，我只要拿到快递员令牌就能进入小区，没有一个身份的认证，总觉得太不安全了
2019年4月 4日 09:20 | # | 引用
Gin 说：
阮老师这个生活化的示例举得极好
2019年4月 4日 09:22 | # | 引用
阿木 说：
这篇文章第一眼看过去感觉很熟悉，对于Auth2.0的四种授权类型以前在这个网站上看过。翻了一下原来是2014年的时候博主写过一篇这个协议的文章。5年过去了，这个协议有什么新的变化吗？
2019年4月 4日 09:47 | # | 引用
Hoe 说：
例子贴合实现, 表达生动, 一看就明白了
2019年4月 4日 10:01 | # | 引用
Di Da 说：
你说的问题OAuth2协议有考虑过
首先，客户端通过用户浏览器请求授权的时候生成的一个code，这个code有效期很短，而且是一次有效。另外，授权服务器还返回了客户端生成的state，保证了客户端对服务端的一个验证。
客户端拿到code之后，会在后台与授权服务器通信，用code换token，这一步没有通过用户浏览器，加上SSL的保护，可以认为通信是安全的。
此外，你说的身份认证，其实是有的，每次与授权服务器都需要提供一个OAuth的secret或用它来加密。如果你连秘钥都丢了，那这就类似你把钥匙给了别人，当然没法阻止别人进你家了。
2019年4月 4日 10:49 | # | 引用
Kevin 说：
阮老师的讲解总是那么简单易懂。
2019年4月 4日 11:44 | # | 引用
hulk 说：
谢谢阮老师，很容易理解
2019年4月 4日 12:23 | # | 引用
xingxiaoli 说：
理解起来很容易，谢谢老师的讲解，期待下一篇文章
2019年4月 4日 13:03 | # | 引用
renton 说：
第三方应用或者网站使用微信号登陆那些应用和网站也是OAuth协议的一部分吗？ 看了老师的文章理解了授权的原理，但还是不怎么清楚登陆的原理
2019年4月 4日 14:10 | # | 引用
粉丝 X 说：
阮老师, 您网站中的文章可不可以转载呢, 我会注明文章来源和作者的 >_
2019年4月 4日 14:37 | # | 引用
scscms 说：
有身份验证的：令牌token是由一组信息（json对象）和公钥加密而来的，比如请求人姓名、系统信息、IP、浏览器信息等等。然后后端获取到token并结合私钥可以解密得到所有信息并核对。所以你复制了别人token去请求是没用的，除非你拥有产生令牌一样的网络环境，比如相同IP、相同系统、相同浏览器等等。
2019年4月 4日 14:45 | # | 引用
davix 说：
在rss里看到一个unread，还以为是因为假期，“每周分享”提前了呢。
当然这篇也很好
2019年4月 4日 16:30 | # | 引用
吕涛 说：
反手一个赞
2019年4月 4日 18:11 | # | 引用
xingvyuan 说：
感谢老师分享，很细致易懂
2019年4月 7日 22:11 | # | 引用
leon 说：
清晰
2019年4月 8日 10:47 | # | 引用
colin 说：
感觉小区物业应该制定一个这个送货授权系统
2019年4月 8日 11:14 | # | 引用
Rebecca 说：
每期必看,支持阮老师
2019年4月 8日 23:21 | # | 引用
看月亮在干嘛 说：
通俗易懂，感谢分享。
2019年4月 9日 09:51 | # | 引用
Mr.zhang 说：
能有Demo串起来就更好了，实践是验证真理的唯一标准
2019年4月11日 13:59 | # | 引用
Darkterror 说：
如果能将Code这一步骤结合至例子里更好了，因为例子里的OAuth直接跳过了Code，直接返回Token。
这点就不能说明为什么必须要有Code，用Code兑换Token的步骤必要性了。
2019年4月22日 18:55 | # | 引用
sameen 说：
清晰易懂，感谢老师！
2019年4月28日 11:08 | # | 引用
Yingcheng 说：
赞，阮老师的文章帮助我理解OAuth2.0
2019年5月24日 15:50 | # | 引用
Bill 说：
不对吧？TOKEN拿到手， 就是可以直接用了， 根本不会检测你的IP和系统 浏览器这些。。。
2019年6月28日 14:29 | # | 引用
miou 说：
世界上没有一种安全机制是绝对安全的
2019年7月 4日 11:56 | # | 引用
王彭飞 说：
老师讲得简介明了
2019年8月 9日 17:44 | # | 引用
FJ 说：
第一步中，快递员点按钮要求授权后你的手机上为什么会显示快递员名字？怎么知道是快递员A而不是B？
2019年9月 3日 13:52 | # | 引用
Chiu 说：
简明扼要，把我零散的想法梳理成线了。
2019年9月25日 17:07 | # | 引用
Chiu 说：
很简单，微信扫码登录第三方网站就是OAuth2.0的一个例子；扫码后会在手机上让用户授权：是否同意登录该网站？
2019年9月25日 17:09 | # | 引用
何胜金 说：
老师讲的太赞了
2019年9月26日 22:07 | # | 引用
simplejava 说：
照你这样说，银行和金融行业的网上业务就别开了
2019年10月23日 12:53 | # | 引用