python

从密码到token, 一个授权的故事 auth2.0 - Bigben - 博客园

文章暂存

systemime
2021-03-24
13 min

摘要.


1

美好的旧时光

我经常怀念三十年前那美好的旧时光, 工作很轻松, 生活很悠闲。

上班的时候偶尔有些 HTTP 的请求发到我这里, 我简单的看一下, 取出相对应的 html 文档,图片,发回去就可以了, 然后就可以继续喝茶聊天。

我的创造者们对我很好, 他们制定的一个简单 HTTP 协议, 就是请求加响应,  尤其是我不用记住是谁刚刚发了 HTTP 请求,   每个请求对我来说都是全新的!

邮件服务器很羡慕我, 他说:老弟,你的生活太惬意了,  哪像我, 每次有人从客户端访问邮箱, 我都得专门给他建立一个会话, 来处理他发的消息, 你倒好, 完全不用管理会话。

这是由应用的特性决定的, 如果邮件服务器不管理会话, 那多个人之间的邮件消息就会完全混到一起了, 乱作一团了。

而 30 年前的 Web 基本上就是文档的浏览而已, 既然是浏览,我作为一个服务器, 为什么要记住谁在一段时间里都浏览了什么文档呢?

2

Session

但是好日子没持续多久, 很快大家就不满足于静态的 Html 文档了, 交互式的 Web 应用开始兴起, 尤其是论坛, 在线购物等网站。

我马上就遇到了和邮件服务器一样的问题, 那就是必须管理会话,必须记住哪些人登录系统,  哪些人往自己的购物车中放了商品,  也就是说我必须把每个人区分开。

这对我来说是个不小的挑战, 由于 HTTP 协议的无状态特性, 我必须加点小手段,才能完成会话管理。

我想出的办法就是给大家发一个会话标识 (session id), 说白了就是一个随机的字符串,每个人收到的都不一样,  每次大家向我发起 HTTP 请求的时候,把这个字符串给一并捎过来, 这样我就能区分开谁是谁了。

3

沉重的负担

大家都很高兴, 可是我就不爽了。

每个人只需要保存自己的 session id,而我需要保存所有人的 session id !  如果访问我的人多了, 就得由成千上万,甚至几十万个。

这对我来说是一个巨大的开销 , 严重的限制了我的扩展能力, 比如说我用两个机器组成了一个集群, 小 F 通过机器 A 登录了系统,  那 session id 会保存在机器 A 上,  假设小 F 的下一次请求被转发到机器 B 怎么办?  机器 B 可没有小 F 的 session id 啊。

有时候我会采用一点小伎俩: session sticky , 就是让小 F 的请求一直粘连在机器 A 上, 但是这也不管用, 要是机器 A 挂掉了, 还得转到机器 B 去。

那我只好做 session 的复制了, 把 session id  在两个机器之间搬来搬去, 快累死了。

后来有个叫 Memcached 的给我支了招: 把 session id 集中存储到一个地方, 所有的机器都来访问这个地方的数据, 这样一来,就不用复制了, 但是增加了单点失败的可能性, 要是那个负责 session 的机器挂了,  所有人都得重新登录一遍, 估计得被人骂死。

我也尝试把这个单点的机器也搞出集群,增加可靠性, 但不管如何, 这小小的 session 对我来说是一个沉重的负担。

4

时间换空间

这几天的晚上我一直在思考, 我为什么要保存这可恶的 session 呢, 只让每个客户端去保存该多好?

可是如果我不保存这些 session id ,  我怎么验证客户端发给我的 session id 的确是我生成的呢?  如果我不去验证,我都不知道他们是不是合法登录的用户, 那些不怀好意的家伙们就可以伪造 session id , 为所欲为了。

嗯,对了,关键点就是验证 !

比如说, 小 F 已经登录了系统, 我给他发一个令牌 (token), 里边包含了小 F 的 user id, 下一次小 F 再次通过 Http 请求访问我的时候, 把这个 token 通过 Http header 带过来不就可以了。

不过这和 session id 没有本质区别啊, 任何人都可以可以伪造,  所以我得想点儿办法, 让别人伪造不了。

那就对数据做一个签名吧, 比如说我用 HMAC-SHA256 算法,加上一个只有我才知道的密钥,  对数据做一个签名, 把这个签名和数据一起作为 token ,   由于密钥别人不知道, 就无法伪造 token 了。

这个 token 我不保存,  当小 F 把这个 token 给我发过来的时候,我再用同样的 HMAC-SHA256 算法和同样的密钥,对数据再计算一次签名, 和 token 中的签名做个比较, 如果相同, 我就知道小 F 已经登录过了,并且可以直接取到小 F 的 user id ,  如果不相同, 数据部分肯定被人篡改过, 我就告诉发送者: 对不起,没有认证。

Token 中的数据是明文保存的(虽然我会用 Base64 做下编码, 但那不是加密), 还是可以被别人看到的, 所以我不能在其中保存像密码这样的敏感信息。

当然, 如果一个人的 token 被别人偷走了, 那我也没办法, 我也会认为小偷就是合法用户, 这其实和一个人的 session id 被别人偷走是一样的。

这样一来, 我就不保存 session id 了, 我只是生成 token , 然后验证 token ,  我用我的 CPU 计算时间获取了我的 session 存储空间 !

解除了 session id 这个负担,  可以说是无事一身轻, 我的机器集群现在可以轻松地做水平扩展, 用户访问量增大, 直接加机器就行。   这种无状态的感觉实在是太好了!


原创 2017-07-03 老刘 码农翻身

1. 我把密码献给你

小梁开发了一个 “信用卡管家” 的程序 , 可以自动从邮箱中读取信用卡相关邮件,分析、汇总,形成一个报表。

小梁找到信用卡达人张大胖试用 : “你的信用卡那么多,看看我这个程序吧, 保准你会爱死它。”

张大胖尝试了几下说: “咦,你这个程序要读取我的网易邮箱啊,那需要用户名 / 密码吧”

“是啊 , 你把密码告诉输入程序不就行了, 我的程序替你加密保存,保证不会泄露。”

“得了吧你, 我可不会告诉你我的密码, 为了方便记忆, 我的密码都是通用的, 万一泄露了就完蛋了”

小梁说:“这样吧,我不保存,我就访问邮箱的时候使用一次, 用完就扔!”

“你以为你是阿里巴巴啊, 有信用背书, 你只是个小网站, 我把密码献给你,总是觉得不安全。就是我信任你,别人能信任你吗?”

小梁想想也是, 这是一个巨大的心理障碍, 每个人都要誓死捍卫自己的密码啊。

2. Token

过了一周, 小梁兴致勃勃地把张大胖拉来看 “信用卡管家” 的升级版。

“升级为 2.0 了啊, 这次不用问你要网易邮箱的用户名和密码了”

“那你怎么访问我的邮箱?”

“很简单,我提供了一个新的入口,使用网易账号登录, 你点了以后,其实就会重定向到网易的认证系统去登录,  网易的认证系统会让你输入用户名和密码,并且询问你是否允许信用卡管家访问网易邮箱, 你确认了以后,就再次重定向到我的‘信用卡管家’网站, 同时捎带一个‘token’ 过来, 我用这个 token 就可以通过 API 来访问网易邮箱了。 在这个过程中, 我根本不会接触到你的用户名和密码,怎么样, 这下满意了吧?”

“你说得轻松, 你这个信用卡管家是个小网站,还没有什么名气, 网易怎么会相信你这个网站呢?”

“我当然要先在网易注册一下啊, 他们会给我发个 app_id 和 app_secret,  我重定向到网易的时候需要把这个东西发过去, 这样网易就知道是‘信用卡管家’这个应用在申请授权了。”

(点击看大图)

张大胖说: “你这重定向来重定向去的, 实际上不就是为了拿到一个 token 吗?”

“对啊,因为你不信任我的信用卡管家, 不让它保存你的密码,只好用 token 的方法了 , 它是网易认证中心颁发的,实际上就代表了你对信用卡管家访问邮箱的授权,所以有了这个 token 就可以访问你的邮箱了”

"对了"  张大胖问题, “你为什么用 Javascript 的方式来读取 token 啊”

“这样我的后端服务器就不用参与了,工作都在前端搞定, 你注意到那个 URL 中的 #号了吗? www.a.com/callback#token=< 网易返回的 token>”

张大胖说: “我知道啊,这个东西叫做 hash fragment,  只会停留在浏览器端, 只有 Javascript 能访问它,并且它不会再次通过 http request 发到别的服务器器, 我想这是为了提高安全性吧。”

小梁说: “没错, 那个 token 非常非常重要,得妥善保存,不能泄露!”

“可是在第 6 步通过重定向,这个 token 以明文的方式发送给了我的浏览器, 虽然是 https ,不会被别人窃取,可是浏览器的历史记录或者访问日志中就能找到, 岂不暴露了?”

小梁说: “这个.... , 我说你这个家伙,安全意识很强烈嘛, 让我想想,有没有更安全的方式。"

3. Authorization  Code + Token

又过了一周,小梁成功地把信用卡管家升级为 3.0.

他对张大胖说: “这次我成功地把那个非常重要的、表示授权的 token 给隐藏起来了, 你要不要看看?”

“你先说说你是怎么隐藏的?”

“其实整体思路和之前的类似,只是我引入了一个叫做 Authorization  Code 的中间层。 当你用网易账号登录的时候, 网易认证中心这一次不给我直接发 token, 而是发一个授权码 (authorization code) ,   我的信用卡管家服务器端取到这个 code 以后,在后台再次访问网易认证中心, 这一次他才发给我真正的 token 。 还是直接上图吧:”

(点击看大图)

张大胖说: “还比较容易理解, 本质上就是你拿着这个返回的授权码在服务器后台‘偷偷地’完成申请 token 的过程, 所以 token 浏览器端根本就接触不到,对吧?”

“什么叫偷偷地申请 token ? 这是我信用卡管家服务器和网易之间的正常交流, 只是你看不到而已。”

“开个玩笑了, 你虽然隐藏了 token, 但是这个授权码确是暴露了啊,你看第 7 步,我在浏览器中都能明文看到,  要是被谁取到, 不也是照样能取到 token 吗?”

小梁说: “我们肯定有防御措施, 比如这个授权码和我的信用卡管家申请的 app_id,app_secret 关联, 只有信用卡管家发出的 token 请求, 网易认证中心才认为合法; 还可以让授权码有时间限制,比如 5 分钟失效,还有可以让授权码只能换一次 token, 第二次就不行了。 ”

“听起来似乎不错, 好吧, 这次我可以放心地使用了!”

4. 后记

本文讲的其实就是就是 OAuth 中的三种认证方式,依次是:

  1. Resource Owner Password Credentials Grant(资源所有者密码凭据许可)

  2. Implicit Grant(隐式许可)

  3. Authorization Code Grant(授权码许可)

还有一种叫做 Client credentials , 用的较少,文章没有涉及。

这些名称有些古怪, 但是本质没那么复杂。 在 OAuth 中,还有几个术语大家可以理解下:

资源所有者 :  就是我们上文的张大胖

资源服务器 : 即网易邮箱

客户端: 就是上文的信用卡管家

授权服务器 : 即上文的网易认证中心

想查看完整的 OAuth 2.0 协议, 可以点击阅读原文

https://mp.weixin.qq.com/s?\_\_biz=MzAxOTc0NzExNg==&mid=2665513566&idx=1&sn=a2688cadbe9c8042ff1abbdf04a8bd5e&chksm=80d67a1db7a1f30b28b93ed2ab29edfbf982b780433e4bfd178e3cc52cb1f9100cc8f923db4f&scene=21#wechat\_redirect https://webcache.googleusercontent.com/search?q=cache:m9gC5jmXqrwJ:https://www.cnblogs.com/bigben0123/p/8334824.html+&cd=7&hl=zh-CN&ct=clnk&gl=hk https://webcache.googleusercontent.com/search?q=cache:m9gC5jmXqrwJ:https://www.cnblogs.com/bigben0123/p/8334824.html+&cd=7&hl=zh-CN&ct=clnk&gl=hk

上次编辑于: 5/20/2021, 7:26:49 AM