你管这破玩意叫 OAuth?

亦凉 2022-10-06 06:56 327阅读 0赞

低并发编程

战略上藐视技术,战术上重视技术

今天,我想登陆豆瓣,看看电影评论,陶冶陶冶情操。

但是,我从来没注册过豆瓣账号,而我又懒得再注册一个,怎么办呢?

我打开豆瓣的官网,笑了,原来豆瓣早就为我这种懒人想到了办法。

#

懒人三步

第一步:在豆瓣官网点击用 QQ 登陆。

65e1a2553f33b6ae1ebfd49752e0d973.png

第二步:跳转到 qq 登录页面输入用户名密码,然后点授权并登录。

1323751230e62aae9622119866e40be5.png

第三步:跳回到豆瓣页面,成功登录。

4f3d3b2be6b931131a03d8836c951b3d.png

太方便了!

但这短短的几秒钟,可不简单,我来给你说说。

#

上帝视角看发生了什么

这几秒钟之内发生的事情,在外行的用户视角看来,就是在豆瓣官网上输了个 qq 号和密码就登录成功了。

在一些细心的用户视角看来,页面经历了从豆瓣到 qq,再从 qq 到豆瓣的两次页面跳转。

但作为一群专业的程序员,我们还应该从上帝视角来看这个过程。

21665d91e10cf4ec33d0db88a00e2837.png

看起来很复杂是吧,我们一步步拆解一下:

第一步:在豆瓣官网点击用 qq 登录

当你点击用 qq 登录的小图标时,实际上是向豆瓣的服务器发起了一个请求。

http:// www.douban.com/leadToAuthorize

豆瓣服务器会响应一个重定向地址,指向 qq 授权登录的页面地址。

http:// www.qq.com/authorize

当然,这个重定向地址还附带了一个回调地址,这是在 QQ 那边登陆成功后需要跳回的豆瓣地址。

http://www.qq.com/authorize?
callback=www.douban.com/callback

这跳回的地址是必然的嘛,不然 QQ 怎么知道在我这边登陆成功后我要干嘛,上杆子找人家 QQ 授权的网站那么多。

这部分的流程是黄色的这部分。

8742a7d1f633800cdee840ff85cfd3e0.png

第二步:跳转到 qq 登录页面输入用户名密码,然后点授权并登录

上一步,浏览器接到重定向地址

http://www.qq.com/authorize?
callback=www.douban.com/callback

自然没什么好说的,乖乖访问过去。

这回访问的就是 QQ 的页面了。

3c6370399d4f5870ca3c73803fabd267.png

用户输入 QQ 号和密码,点击授权并登陆,这里走 QQ 服务器自己的校验逻辑,与豆瓣毫无关系。

若校验成功,会响应给浏览器一个重定向地址

www.douban.com/callback

没错,就是上一步传给 QQ 服务器的 callback 参数!

但除了这个地址外,还附上了一个 code,我们叫它授权码

www.douban.com/callback?code=xxx

这个 code 是豆瓣服务唯一关心的事情,至于你那边如何校验用户,无所谓,只要最终能给我一个 code 码,我就认为这个用户在你那里登陆成功了。

这部分的流程是黄色的这部分。

01d953ff1f399583d8bf8b5a4ea055d7.png

第三步:跳回到豆瓣页面,成功登录

这一步背后的过程其实是最繁琐的,但对于用户来说是完全感知不到的。

用户在 QQ 登录页面点击授权登陆后,就直接跳转到豆瓣首页了,但其实经历了很多隐藏的过程。

首先接上一步,QQ 服务器在判断登录成功后,使页面重定向到之前豆瓣发来的 callback 并附上 code 授权码。

www.douban.com/callback?code=xxx

浏览器接到重定向,乖乖发起请求,此时请求的是豆瓣服务器

豆瓣服务器收到请求后,对 QQ 服务器发起了两次请求:

  1. 用拿到的 code 去换 token

  2. 再用拿到的 token 换取用户信息

这个 code 和 token 都是有失效时间的,也因此保证了只要不在短时间内泄漏出去,就不会有安全风险。

拿到用户信息之后,就返回给了浏览器。注意此时的浏览器上是豆瓣的首页,豆瓣也因此可以将你的个人信息展示出来。

f46dfe7143b17ce9478b25edf9a52483.png

这部分的流程是黄色的这部分。

47b55735b48d2cb3aac850267d7f595f.png

至此,整个过程结束。

这个破玩意,就叫做 OAuth 2.0 协议

这个流程目的是让大家从全局了解 oauth2.0 协议实际上发生了什么,并仅仅以 oauth 的其中一种模式,授权码模式进行讲解。

如想了解更多模式,以及每次的请求和响应的标准齐全的参数,推荐读一下阮一峰的文章。

http://www.ruanyifeng.com/blog/2014/05/oauth\_2\_0.html

#

为啥要这么跳来跳去

为什么,要这么麻烦呢?跳来跳去的。

其实之所以有这个协议,我总结起来有两点原因:

懒 + 不信任

是指用户懒。

如果用户不那么懒,直接在豆瓣上新注册一个账号就好了。

不信任是什么意思呢?

如果用户信任豆瓣网站,那完全可以让用户在豆瓣网站输入 QQ 的用户名和密码,由豆瓣传给 QQ 服务器做校验,并返回用户信息。

ca0c3c1703b034dbaab5b7f7ebd5cdae.png

但这是不可能的,你愿意把你的 QQ 号和密码给豆瓣看到?

更甚者,如果 QQ 信任豆瓣,用户也信任豆瓣,那 QQ 也可以把自己的数据库直接拷贝给豆瓣,然后豆瓣就可以完全自己拥有一套 QQ 用户数据了,也就可以让用户使用 QQ 登录。

65543230bbf03ceb950efbab790cc748.png

当然,这也是不可能的。

所以就有了 OAuth 这种协议,你进行第三方授权时(文中的QQ),用户名和密码是不经过目标服务器的(文中的豆瓣),这保证了授权的安全性

第三方授权服务器只给目标服务器返回有时效性的 code 和 token,目标服务器通过这个去第三方资源服务器,换取用户信息,这达成了拿到用户信息的目的。

所以总的来说,oauth 协议,就是由于三者(用户、目标、第三方)相互不信任,又想使用第三方服务器的授权功能,以及获取第三方服务器存储的用户信息,而产生的一个办法。

这个破玩意,就叫做 OAuth 2.0 协议

哦,上面好像说过了。

#

c974c18d6caaff8ab3ce14c64c2dbe40.png

礼物

了解了上述过程后,代码自然就不难写了。

这里我实现了一个极简版的 oauth2.0 用于体验这个过程,大家可以参考下。

项目结构非常简单,只有两个模块,分别是豆瓣和QQ,分别启动即可。

20749e630c172b827b74802667d24b7c.png

最终效果也非常简单清晰,下面请忍受 low 逼的显示效果

第一步,登陆豆瓣页面。

c96912b83a498d686510d7909c57b952.png

第二步,使用 QQ 页面进行授权。

1002922e3fe68b4b23a6bb0c823f981f.png

第三步,授权成功跳回豆瓣首页。

953a19df1bac519061f57cbb4647d7b6.png

想获得这份源码的同学,可以关注“低并发编程”公众号,然后回复【oauth】领取

发表评论

表情:
评论列表 (有 0 条评论,327人围观)

还没有评论,来说两句吧...

相关阅读

    相关 玩意 CPU ?

    每次回家开灯时你有没有想过,用你按的简单开关实际上能打造出复杂的 CPU 来,只不过需要的数量会比较多,也就几十亿个吧。 伟大的发明 过去200年人类最重要的发明是什么?蒸

    相关 玩意 OAuth

    低并发编程 战略上藐视技术,战术上重视技术 今天,我想登陆豆瓣,看看电影评论,陶冶陶冶情操。 但是,我从来没注册过豆瓣账号,而我又懒得再注册一个,怎么办呢? 我打

    相关 玩意 OAuth

    低并发编程 战略上藐视技术,战术上重视技术 今天,我想登陆豆瓣,看看电影评论,陶冶陶冶情操。 但是,我从来没注册过豆瓣账号,而我又懒得再注册一个,怎么办呢? 我打