一文带你搞懂 OAuth2.0
最近好久没有发文章了,但并不意味着停止了学习,哈哈哈~
今天给大家带来了关于 OAuth2.0 的相关文章,说实话 OAuth2.0 我也是费了好大力气才稍稍理解的,虽然我们每天都会用到(使用 QQ 授权登录 QQ 音乐、和平精英等等),但是背后的设计实现思想还是蛮复杂的,并且有很多地方值得推敲,今天我就分几个方面带大家重新领略下 OAuth2.0 的设计实现流程和思想,希望能让大家一读就会!会了还想读!读了接着会!
话不多说,开始正文:
1 简单介绍
技术 RFC:https://www.rfc-editor.org/rfc/rfc6749.html,本文部分内容会参考该文档部分内容。
OAuth 是 Open Authorization,即“开放授权”的简写。OAUTH 协议为用户资源的授权提供了一个安全的、开放而又简易的标准。OAuth2.0 是 OAuth 协议的延续版本,但不向前兼容 OAuth 1.0。OAuth 2.0 授权框架支持第三方应用程序获取对 HTTP 服务的有限访问,通过编排审批交互来代表资源所有者资源所有者和 HTTP 服务之间,或通过允许第三方应用程序以自己的名义获取访问。现在百度开放平台,腾讯开放平台等大部分的开放平台都是使用的 OAuth 2.0 协议作为支撑。
OAuth2.0 解决的问题:
需要第三方应用存储资源所有者的凭证以备将来使用,通常是密码以明文,服务器仍须支持密码验证密码固有的安全弱点。
第三方应用程序获得对资源的过度广泛访问所有者的受保护资源,使资源所有者没有任何的有限子集限制持续时间或访问的能力资源。
资源所有者不能撤销对单个第三方的访问权限不撤销对所有第三方的访问,并且必须这样做修改第三方用户密码。
任何第三方应用程序的妥协将导致妥协终端用户的密码以及所有受该密码保护的数据密码。
2 流程梳理
OAuth2.0 总体流程:
我们来用现实的事件来举个例子——
使用QQ登录极客时间
(够现实了吧)
(1)首先我们了解状况:QQ 的服务器和极客时间的服务器肯定不是同一个服务器,而且用户数据的存储方式也可能也不同
(2)其次我们在选择用 QQ 登录极客时间时会重定向出一个网页,这个网页是 QQ 的网页
然后我们画一个图:
其中,实线部分是我们用户真正操作的流程,而虚线部分则是服务内部的流程。
由此,我们知道,QQ 服务器,作为我们将要登录的网站的第三方认证服务,必须事先保存我们用户的信息,以便认证时使用。
3 四种角色
resource owner(资源拥有者):用户,能够授予对受保护资源的访问权的实体。
resource server(资源服务器):将要访问的服务,托管受保护资源的服务器,能够接受以及使用访问令牌响应受保护的资源请求。
client(客户端):即 Web 浏览器,请求受保护资源的应用程序资源所有者及其授权。
authorization server(认证服务器):三方授权服务器,服务提供商专门用来处理认证授权的服务器,认证成功后向客户端发出访问令牌资源所有者身份验证,获取授权。
4 四种实现方式
在 OAuth2.0 中最常用的当属授权码模式,也就是我们上文讲述的实现,除此之外还有简化模式、密码模式、客户端模式等,模式的不同当然带来的就是流程和访问方式及请求参数的不同,由于其他三种模式并不常用,因此只讲述基本流程,重点还是在授权码模式中,下面我们开始分析:
4.1 授权码模式 Authorization Code(最常用)
(A) 用户访问客户端,客户端将用户重定向到认证服务器;
(B) 用户选择是否授权;
(C) 如果用户同意授权,认证服务器重定向到客户端事先指定的地址,而且带上授权码(code);
(D) 客户端收到授权码,带着前面的重定向地址,向认证服务器申请访问令牌;
(E) 认证服务器核对授权码与重定向地址,确认后向客户端发送访问令牌和更新令牌(可选)。
4.2 简化模式 Implicit
(A) 客户端将用户导向认证服务器, 携带客户端 ID 及重定向 URI;
(B) 用户是否授权;
(C) 用户同意授权后,认证服务器重定向到 A 中指定的 URI,并且在 URI 的
Fragment
中包含了访问令牌;(D) 浏览器向资源服务器发出请求,该请求中不包含 C 中的
Fragment
值;(E) 资源服务器返回一个网页,其中包含了可以提取 C 中
Fragment
里面访问令牌的脚本;(F) 浏览器执行 E 中获得的脚本,提取令牌;
(G) 浏览器将令牌发送给客户端。
4.3 密码模式 Resource Owner Password Credentials
(A) 资源所有者提供用户名密码给客户端;
(B) 客户端拿着用户名密码去认证服务器请求令牌;
(C) 认证服务器确认后,返回令牌;
4.4 客户端模式 Client Credentials
(A) 客户端发起身份认证,请求访问令牌;
(B) 认证服务器确认无误,返回访问令牌。
5 动手实现一个 OAuth2.0 鉴权服务
具体代码见 GitHub:https://github.com/ibarryyan/oauth2
5.1 整体流程
5.2 代码
5.2.1 Client
handler
5.2.2 Server
handler
login.html
auth.html
6 小总结
OK,到这里 OAuth2.0 的讲解就快要结束了,当然由于时间关系,文章中有些内容讲解的可能不够详细,希望读者朋友能够给予指出。文中的代码案例主要采用 Go 语音进行实现,除此之外 Spring 社区中也有相关的实现,语言并不是局限。在实际的项目中可能会更加的复杂,但是思想都是一致的,在业务上可能或多或少有所补充,这就需要我们一起在工作中不断学习了。
最后,有一个小思考想分享一下,为什么用户在第三方认证完成后使用返回的 Code 换取 Token,而不是直接使用 Code 进行后续的步骤呢?
在这里我先给出我的思考和一位前辈的指点:
首先当然是安全,一般 Code 只能兑换一次 token,如果你获取 Code 后,无法授权,则系统自然会发现被黑客攻击了,会重新授权,那么之前的 token 就无效了。
其次还是为了安全,Code 是服务端生成的,防止 Code 被拿到后多次请求被认为是恶意请求,而 token 每次请求后都会变化,且有过期时间。
(接下来的原因还请读者朋友们积极讨论)
参考:
https://razeen.me/posts/oauth2-protocol-details
https://www.rfc-editor.org/rfc/rfc6749.html
https://zhuanlan.zhihu.com/p/509212673
https://www.zhihu.com/question/275041157/answer/1342887745
版权声明: 本文为 InfoQ 作者【Barry Yan】的原创文章。
原文链接:【http://xie.infoq.cn/article/ae6ebe766c5ba67f8dc102626】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论