你管这破玩意叫 OAuth?

本文详细解析了OAuth2.0协议的工作原理,通过一个用户在豆瓣使用QQ登录的实例,展示了从点击登录到授权成功的全过程。OAuth2.0协议旨在在用户、目标网站和第三方服务之间建立安全的授权机制,避免直接传递敏感信息,确保用户数据安全。通过阅读,读者可以了解到OAuth2.0协议的授权码模式及其在实际应用中的价值。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

低并发编程

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

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

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

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

懒人三步

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

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

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

太方便了!

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

上帝视角看发生了什么

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

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

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

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

第一步:在豆瓣官网点击用 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 授权的网站那么多。

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

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

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

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

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

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

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

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

www.douban.com/callback

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

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

www.douban.com/callback?code=xxx

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

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

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

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

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

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

www.douban.com/callback?code=xxx

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

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

1. 用拿到的 code 去换 token

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

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

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

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

至此,整个过程结束。

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

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

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

http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

为啥要这么跳来跳去

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

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

懒 + 不信任

是指用户懒。

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

不信任是什么意思呢?

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

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

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

当然,这也是不可能的。

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

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

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

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

哦,上面好像说过了。

礼物

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

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

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

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

第一步,登陆豆瓣页面。

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

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

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

### 回答1: OAuth2.0 是一个用于授权的开放标准协议,它允许用户授权第三方应用程序(如社交媒体应用程序)访问他们的受保护资源(如照片、视频等)。OAuth2.0 的主要目的是为了减少用户在第三方应用程序和资源服务提供者之间共享凭证的需求,从而提高安全性并减少安全风险。 OAuth2.0 的主要组成部分包括: 1.授权服务器:用于管理用户授权的服务器,验证用户身份并颁发访问令牌。 2.资源服务器:存储和管理受保护的资源。 3.客户端应用程序:代表用户请求访问受保护资源的应用程序。 4.访问令牌:由授权服务器颁发给客户端应用程序,用于访问资源服务器中受保护的资源。 5.刷新令牌:用于更新访问令牌,以便客户端应用程序可以持续访问受保护的资源。 使用 OAuth2.0,用户不需要将他们的用户名和密码直接提供给第三方应用程序,从而提高了安全性和隐私保护。但是,使用 OAuth2.0 也存在一些安全风险,例如客户端应用程序的恶意行为可能导致访问令牌泄漏。为了解决这些问题,开发者需要遵循 OAuth2.0 的最佳实践,并在实现过程中注意安全性。 ### 回答2: OAuth2.0(开放授权)是一种授权框架,用于授权第三方应用程序访问用户资源。它允许用户将他们在某个资源所有者(如Facebook、Google)处的身份验证信息提供给其他站点或应用程序进行访问,而不需要共享他们的用户名和密码。OAuth2.0所解决的问题是用户如何安全地授权第三方应用程序访问他们的个人数据。 在过去,用户通常需要将他们的用户名和密码提供给第三方应用程序,以使其能够访问他们的个人数据。然而,这样的方式存在很多潜在风险,因为用户的敏感信息可能会被盗取或滥用。为了解决这个问题,OAuth2.0允许用户通过对资源所有者进行身份验证来授权第三方应用程序的访问权限。 OAuth2.0通过引入授权服务器和令牌的概念来实现这里的授权过程。当用户希望授权第三方应用程序时,他们将被重定向到授权服务器,在授权服务器上他们输入其凭证进行身份验证。一旦身份验证成功,授权服务器将向第三方应用程序颁发一个访问令牌,该令牌允许第三方应用程序代表用户访问用户资源。 这种方式的优点在于用户不需要共享其用户名和密码,只需授权给第三方应用程序访问特定资源的权限。如果第三方应用程序滥用权限,用户可以随时撤销访问令牌,从而终止对其个人数据的访问。 总之,OAuth2.0是一种安全的授权框架,通过授权服务器和令牌概念,解决了用户如何安全授权第三方应用程序访问其个人数据的问题。 ### 回答3: OAuth2.0是一种开放授权协议,用于在不泄露用户账号密码的情况下,允许用户授权第三方应用或网站访问其受保护的资源。 OAuth2.0协议的主要目的是解决用户在多个应用间共享资源时所面临的问题。在传统的授权方式中,用户需要提供自己的账号密码给第三方应用,这样做存在安全风险,因为第三方应用可能会滥用这些信息。同时,用户在每个应用中都需要输入账号密码,非常繁琐。 OAuth2.0采用了一种更安全且更便捷的授权方式。首先,用户只需要向授权服务器提供一次账号密码,而不是向每个应用提供。授权服务器会颁发一个授权码给第三方应用,该授权码是一次性的,只能用于获取特定资源。第三方应用通过这个授权码访问受保护的资源,而无需知道用户的账号密码。 另外,OAuth2.0还引入了不同的授权模式,以适应不同应用场景。常见的授权模式包括授权码模式、隐式模式、密码模式和客户端凭证模式等。每种授权模式都有自己的特点和适用场景。 综上所述,OAuth2.0解决了用户在多个应用间共享资源时的安全和便捷性问题。它可以保护用户的账号密码不被第三方应用获取,同时简化了用户登录过程,提高了用户体验。同时,OAuth2.0的广泛应用也促进了应用间的互操作性和数据共享,推动了互联网生态的发展。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值