在微服务架构中认证和授权是最基础的服务能力,其中这一块行业类的标准就是OAuth2 和 SSO ,而OAuth2 和 SSO 可以归类为“用户管理和身份验证”工具,OpenID Connect 1.0是 OAuth 2.0 协议之上的一个简单身份层。
OAuth 2.0(访问委托的开放标准),它是一个授权框架,使第三方应用程序能够代表资源所有者通过协调资源所有者和 HTTP 服务之间的批准交互,或通过允许第三方应用程序获得对 HTTP 服务的有限访问权限代表自己获取访问权限;
OAuth 2.0 是一种授权协议,而不是身份验证协议。因此,它主要被设计为授予对一组资源(例如,远程 API 或用户数据)的访问权限的一种方式。
OAuth 2.0 使用访问令牌。访问令牌是代表最终用户访问资源的授权的一段数据。OAuth 2.0 没有为访问令牌定义特定格式。但是,在某些情况下,经常使用 JSON Web Token (JWT) 格式。这使令牌发行者能够在令牌本身中包含数据。此外,出于安全原因,访问令牌可能有到期日期。
角色的思想是OAuth2.0授权框架核心规范的一部分。这些定义了 OAuth 2.0 系统的基本组件,如下所示:
(1)资源所有者:拥有受保护资源并可以授予访问权限的用户或系统。
(2)客户端:客户端是需要访问受保护资源的系统。要访问资源,客户端必须持有适当的访问令牌。
(3)授权服务器:该服务器接收来自客户端的访问令牌请求,并在资源所有者成功验证和同意后发出这些请求。授权服务器公开两个端点:授权端点,它处理用户的交互式身份验证和同意,以及令牌端点,它涉及机器对机器的交互。
(4)资源服务器:保护用户资源并接收来自客户端的访问请求的服务器。它接受并验证来自客户端的访问令牌,并将适当的资源返回给它。
范围是 OAuth 2.0 中的一个重要概念。它们用于准确指定可以授予资源访问权限的原因。可接受的范围值以及它们与哪些资源相关,取决于资源服务器。
OAuth 2授权服务器在Resource Owner授权访问后可能不会直接返回Access Token。相反,为了更好的安全性,可以返回授权码,然后将其交换为访问令牌。此外,授权服务器还可以使用访问令牌颁发刷新令牌。与访问令牌不同,刷新令牌通常有很长的有效期,并且可以在后者到期时交换为新的访问令牌。由于刷新令牌具有这些属性,因此客户端必须安全地存储它们。
在最基本的层面上,在可以使用 OAuth 2.0 之前,客户端必须从授权服务器获取自己的凭证、_client id_ 和客户端密码,以便在请求访问令牌时识别和验证自己。
使用 OAuth 2.0,访问请求由客户端发起,例如移动应用程序、网站、智能电视应用程序、桌面应用程序等。令牌请求、交换和响应遵循以下一般流程
(1)客户端向授权服务器请求授权(授权请求),提供客户端 ID 和密码作为标识;它还提供范围和端点 URI(重定向 URI)以将访问令牌或授权码发送到。
(2)授权服务器对客户端进行身份验证并验证请求的范围是否被允许。
(3)资源所有者与授权服务器交互以授予访问权限。
(4)授权服务器使用授权代码或访问令牌重定向回客户端,具体取决于授权类型,这将在下一节中进行解释。也可以返回刷新令牌。
(5)使用访问令牌,客户端请求从资源服务器访问资源。
在 OAuth 2.0 中,授权是客户端为获得资源访问授权而必须执行的一组步骤。授权框架提供了多种授权类型来应对不同的场景:
(1)授权码授予:授权服务器返回一个一次性授权码给客户端,然后用它换取访问令牌。对于可以在服务器端安全地进行交换的传统 Web 应用程序,这是最佳选择。单页应用程序 (SPA) 和移动/本机应用程序可能会使用授权码流程。然而,这里不能安全地存储客户端机密,因此在交换期间的身份验证仅限于单独使用客户端 ID。更好的替代方法是使用 PKCE grant 的授权代码,如下所示。
(2)隐式授予:一种简化的流程,其中访问令牌直接返回给客户端。在隐式流程中,授权服务器可能会返回访问令牌作为回调 URI 中的参数或作为对表单发布的响应。由于潜在的令牌泄漏,第一个选项现已弃用。
(3)具有代码交换证明密钥 (PKCE) 的授权代码授予:此授权流程类似于授权代码授予,但具有使其对移动/本机应用程序和 SPA 更安全的额外步骤。
(4)资源所有者凭据授权类型:此授权要求客户端首先获取资源所有者的凭据,这些凭据将传递给授权服务器。因此,它仅限于完全信任的客户端。它的优点是不涉及到授权服务器的重定向,因此适用于重定向不可行的用例。
(5)客户端凭证授权类型:用于非交互式应用程序,例如自动化流程、微服务等。在这种情况下,应用程序本身通过使用其客户端 ID 和密码进行身份验证。
(6)设备授权流程:允许应用程序在输入受限设备(例如智能电视)上使用的授权。
(7)刷新令牌授予:涉及将刷新令牌交换为新访问令牌的流程。
OpenID Connect 1.0 是 OAuth 2.0 协议之上的一个简单身份层。它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份,并以可互操作和类似 REST 的方式获取有关最终用户的基本配置文件信息。
OpenID Connect 允许所有类型的客户端(包括基于 Web 的客户端、移动客户端和 JavaScript 客户端)请求和接收有关经过身份验证的会话和最终用户的信息。该规范套件是可扩展的,允许参与者在对他们有意义时使用可选功能,例如身份数据加密、OpenID 提供者发现和注销。
SSO(单点登录)是Buzzfeed 实现的的单点登录认证代理,BuzzFeed 开发的身份验证和授权系统旨在为访问我们员工使用的许多内部 Web 应用程序提供安全的单点登录体验。
这里推荐大家一个比较成熟的SSO的案例https://github.com/buzzfeed/sso。
SSO依靠谷歌作为其权威的 OAuth2 提供商,并根据特定的电子邮件域对用户进行身份验证。每个上游可能需要基于 Google 群组成员资格的进一步授权。
SSO背后的主要思想是“双 OAuth2”流程,其中sso-authOAuth2 提供者为sso-proxy,而 Google 是sso-auth。SSO建立在 Bitly 的开源oauth2_proxy之上。
简而言之,如果用户访问sso-proxy受保护的服务 ( foo.sso.example.com) 并且没有会话 cookie,他们将被重定向到sso-auth( sso-auth.example.com)。
如果用户没有 的会话 cookie sso-auth,系统会提示他们通过通常的 Google OAuth2 流程登录,然后重定向回sso-proxy他们现在将要登录的位置(到 foo.sso.example.com)。
如果用户确实有会话 cookie sso-auth(例如,他们已经登录bar.sso.example.com),他们将被透明地重定向回proxy他们将要登录的位置,而无需通过 Google OAuth2 流程。
sso-proxy透明地重新验证和刷新用户的会话sso-auth。
目前Spring对OAuth2和OpenID Connect1.0的支持力度还是蛮大的,比如Spring Authorization Server。
Spring Authorization Server 是一个框架,它提供OAuth 2.1和OpenID Connect 1.0规范以及其他相关规范的实现。它建立在Spring Security之上,为构建 OpenID Connect 1.0 身份提供者和 OAuth2 授权服务器产品提供安全、轻量级和可定制的基础。
Spring Security 是一个功能强大且高度可定制的身份验证和访问控制框架。它是保护基于 Spring 的应用程序的事实标准。
Spring Security 是一个专注于为 Java 应用程序提供身份验证和授权的框架。与所有 Spring 项目一样,Spring Security 的真正强大之处在于它可以轻松扩展以满足自定义需求。
关于OAuth 2.1的最新规格可以参考https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-05。
关于OpenID Connect 1.0的最新规格可以参考https://openid.net/specs/openid-connect-core-1_0.html。
https://item.jd.com/14337086.html编辑https://item.jd.com/14337086.html
“RocketMQ消息中间件实战派上下册”是我既“Spring Cloud Alibaba微服务架构实战派上下册”之后,又一本历时超过1年半的巨无霸技术实战类型的书籍。
为了提高读者阅读本书的体验性,本书总共设计了十个特色,下面我一一的给技术小伙伴阐述一下。
本书将RocketMQ的技术原理和最佳实践体系化,按照由浅到深的顺序呈现给读者,使读者可以按照章节顺序按部就班地学习。当学习完全书内容之后,读者不仅能熟悉RocketMQ的核心原理,还能充分理解RocketMQ的“根”。
本书不仅包括RocketMQ4.x(4.9.2版本)的核心原理分析和最佳实践,还包括RocketMQ5.x(5.1. 0版本)的新特性分析和最佳实践。
本书精心研究了程序类、架构类知识的认知规律,全书共分为6篇:①基础;②进阶;③高级;④高并发、高可用和高性能;⑤应用;⑥新特性,是一条相对科学的主线,让读者快速从“菜鸟”向“RocketMQ分布式架构实战高手”迈进。
一图胜于文,书中在涉及原理、架构、流程的地方配有插图,以便读者更加直观地理解。
本书创造性地分析了RocketMQ具备高并发、高可用和高性能的功能及原理,并从架构的视角展开分析,这些也是程序员进阶为技术专家或架构师必备的技能。
以下为从架构师和技术专家的视角分析RocketMQ典型案例,读者阅读完本书之后,也能够达到这样的水准。
本书介绍了大量的实战案例,能让读者“动起来”,在实践中体会功能,而不只是一种概念上的理解。
在讲解每一个知识模块时,我在思考:在这个知识模块中,哪些是读者必须实现的“标准动作”(实例);哪些“标准动作”是可以先完成的,以求读者能快速有一个感知;哪些“标准动作”具有一定难度, 需要放到后面完成。读者在实践完书中的案例之后,就能更容易理解那些抽象的概念和原理了。
本书的目标之一是,让读者在动手中学习,而不是“看书时好像全明白了,一动手却发现什么都不会”。通过体系化的理论和实战案例去培养读者的主动学习能力,这样本书的价值就会被最大化。
本书相信“知行合一”的理念,而不是“只知,而不行”,避免开发人员出现眼高手低的现象。尤其是在技术面试过程中,面试官更加看重的是既懂原理,又能够主动是实践技术的技术人。
本书以系统思维的方式,从业务功能视角剖析 RocketMQ 底层的技术原理,使读者具备快速阅读 RocketMQ 框架源码的能力。读者只有具备了这种能力,才能举一反三,实现更复杂的功能,应对更复杂的应用场景。
本书向读者展示了如何修改 RocketMQ 源码,并快速验证案例分析。这样,读者可以从中学到参与开源的技能,并为后续自己能够参与开源做准备。
为了提高读者阅读本书的体验,在有上下两册的前提下(巨无霸,超过800页),出版社不吝啬印刷成本,依然采用双色印刷。
为了提高读者学习RocketMQ的效率,我这边结合我自身从RocketMQ小白到RocketMQ专家的经历,为读者汇总了一条最佳学习路径。
RocketMQ是我深度参与研究的一款开源消息中间件,无论是从源码,还是架构场景,我都提炼了很多最佳实践。
在开源领域,技术小伙伴可以使用的开源消息中间件非常的多,比如Kafka、Pulsar等,我之所以选择研究RocketMQ,除了工作内容和角色需要之外,更多的还是自己感兴趣,因此我建议技术小伙伴一定要先培养自己的兴趣,兴趣才是提升技术硬实力的第1要素。
当然我并不止研究了RocketMQ,还研究了Pulsar和Kafka等(包括开源消息中间件生态中的主流框架),只是本书作为一本关于RocketMQ实战派的书籍,我必须要以RocketMQ为主。
假如技术小伙伴想成为Java领域的架构师或者技术专家,我强烈建议你去研究RocketMQ,它会给你带来很多意想不到的技术和架构方法论的收获,这个也是我写本书的主要目的之一。
建议技术小伙伴按照本书设计的学习路线,逐章的去阅读和实战,这样学习效果会更好。
如果技术小伙伴有技术交流的,可以通过博文视点官方的读者群找到我的联系方式,并与我沟通,我会实时的解答读者的疑问。
本文公众号“架构随笔录”
本人视频号“架构随笔录”
2021年我和博文视点合作了一本技术类型的书籍“Spring Cloud Alibaba微服务架构实战派上下册”,它是我涉足知识输出领域以来的第一本书,同时它也是我自己积累的技术池中部分技术的产出。
为了写好那本书,我几乎花费了所有的休息时间,并主动的承担了书的售后技术辅导和咨询的职责(几乎是有问必答,坚持了整整两年)。
所谓有付出总会有回报,Alibaba这本书的销量还不错,我也因此获得了博文视点颁发的2021年度优秀作者。
我很清楚,这个是博文视点为了鼓励我继续去用心写书,因此我又花了接近1年半的时间去写了RocketMQ消息中间件实战派上下册这本书。
所谓一分耕耘一份收获,我将我对RocketMQ的理解体系化的输出给喜欢技术的技术人,希望真的对大家有帮助。
2022年,我开始涉足技术直播和技术讲师领域,并和博文视点合作几次技术直播,直播效果还不错,再加上我孜孜不倦的布道“Spring Cloud Alibaba微服务架构实战派上下册”这本书相关的技术,并且这些技术都是有助于“技术人”快速成长的,因此也获得了博文视点颁发的“2023技术成长领路人”这个技术奖项,这个奖项也是为了鼓励我继续通过技术直播的方式给技术人去布道技术,因此只要我有时间,我就会孜孜不倦的去讲和聊技术。
2022年,我开始涉足企业培训和相关技术直播,并和“四维口袋”合作了几次技术直播,并荣获了2022 KVP最具价值技术专家的技术奖项。