mirror of
https://github.com/zhwei820/learn.lianglianglee.com.git
synced 2025-11-16 22:23:45 +08:00
fix img
This commit is contained in:
@@ -160,7 +160,7 @@ function hide_canvas() {
|
||||
<h4>OAuth2 协议的应用场景</h4>
|
||||
<p>在常见的电商系统中,通常会存在类似工单处理的系统,而工单的生成在使用用户基本信息的同时,势必也依赖于用户的订单记录等数据。为了降低开发成本,假设我们的整个商品订单模块并不是自己研发的,而是集成了外部的订单管理平台,此时为了生成工单记录,就必须让工单系统读取用户在订单管理平台上的订单记录。</p>
|
||||
<p>在这个场景中,难点在于<strong>只有得到用户的授权</strong>,才能同意工单系统读取用户在订单管理平台上的订单记录。那么问题就来了,工单系统如何获得用户的授权呢?一般我们想到的方法是用户将自己在订单管理平台上的用户名和密码告诉工单系统,然后工单系统通过用户名和密码登录到订单管理平台并读取用户的订单记录,整个过程如下图所示:</p>
|
||||
<p><img src="assets/Cgp9HWDewCGALXXGAABc1HLmoQs176.png" alt="Drawing 0.png" /></p>
|
||||
<p><img src="assets/Cgp9HWDewCGALXXGAABc1HLmoQs176.png" alt="png" /></p>
|
||||
<p>案例系统中用户认证和授权交互示意图</p>
|
||||
<p>上图中的方案虽然可行,但显然存在几个严重的缺点:</p>
|
||||
<ul>
|
||||
@@ -170,11 +170,11 @@ function hide_canvas() {
|
||||
</ul>
|
||||
<p>既然这个方案存在如此多的问题,那么有没有更好的办法呢?答案是肯定的,<strong>OAuth2 协议</strong>的诞生就是为了解决这些问题。</p>
|
||||
<p>首先,针对密码的安全性,在 OAuth2 协议中,密码还是由用户自己保管,避免了敏感信息的泄露;其次,OAuth2 协议中提供的授权具有明确的应用范围和有效期,用户可以根据需要限制工单系统所获取授权信息的作用效果;最后,如果用户对自己的密码等身份凭证信息进行了修改,只需通过 OAuth2 协议重新进行一次授权即可,不会影响到相关联的其他第三方应用程序。</p>
|
||||
<p><img src="assets/CioPOWDewCqACykjAABqSG9fZc8154.png" alt="Drawing 1.png" /></p>
|
||||
<p><img src="assets/CioPOWDewCqACykjAABqSG9fZc8154.png" alt="png" /></p>
|
||||
<p>传统认证授权机制与 OAuth2 协议的对比图</p>
|
||||
<h4>OAuth2 协议的角色</h4>
|
||||
<p>OAuth2 协议之所有能够具备这些优势,一个主要的原因在于它把整个系统涉及的各个角色及其职责做了很好地划分。OAuth2 协议中定义了四个核心的角色:<strong>资源、客户端、授权服务器和资源服务器</strong>。</p>
|
||||
<p><img src="assets/CioPOWDewDCAIiUOAAB24Bx2cBU249.png" alt="Drawing 2.png" /></p>
|
||||
<p><img src="assets/CioPOWDewDCAIiUOAAB24Bx2cBU249.png" alt="png" /></p>
|
||||
<p>OAuth2 协议中的角色定义</p>
|
||||
<p>我们可以把 OAuth2 中的角色与现实中的应用场景对应起来。</p>
|
||||
<ul>
|
||||
@@ -201,7 +201,7 @@ function hide_canvas() {
|
||||
<li>scope:指定了可访问的权限范围,这里指定的是访问 Web 资源的“webclient”。</li>
|
||||
</ul>
|
||||
<p>现在我们已经介绍完令牌,你可能会好奇这样一个令牌究竟有什么用?接下来,我们就来看如何使用令牌完成基于 OAuth2 协议的授权工作流程。整个流程如下图所示:
|
||||
<img src="assets/CioPOWDewDyAFnrhAABs_ltusFE367.png" alt="Drawing 3.png" /></p>
|
||||
<img src="assets/CioPOWDewDyAFnrhAABs_ltusFE367.png" alt="png" /></p>
|
||||
<p>基于 OAuth2 协议的授权工作流程图</p>
|
||||
<p>我们可以把上述流程进一步展开梳理。</p>
|
||||
<ul>
|
||||
@@ -213,26 +213,26 @@ function hide_canvas() {
|
||||
<h4>OAuth2 协议的授权模式</h4>
|
||||
<p>在整个工作流程中,最为关键的是第二步,即获取用户的有效授权。那么如何获取用户授权呢?在 OAuth 2.0 中,定义了四种授权方式,即<strong>授权码模式(Authorization Code)、简化模式(Implicit)、密码模式(Password Credentials)和客户端模式(Client Credentials)</strong>。</p>
|
||||
<p>我们先来看最具代表性的授权码模式。<strong>当用户同意授权后,授权服务器返回的只是一个授权码,而不是最终的访问令牌</strong>。在这种授权模式下,需要客户端携带授权码去换令牌,这就需要客户端自身具备与授权服务器进行直接交互的后台服务。</p>
|
||||
<p><img src="assets/CioPOWDewEWARSNPAACJjFnruAQ327.png" alt="Drawing 4.png" /></p>
|
||||
<p><img src="assets/CioPOWDewEWARSNPAACJjFnruAQ327.png" alt="png" /></p>
|
||||
<p>授权码模式工作流程图</p>
|
||||
<p>我们简单梳理一下授权码模式下的执行流程。</p>
|
||||
<p>首先,用户在访问客户端时会被客户端导向授权服务器,此时用户可以选择是否给予客户端授权。一旦用户同意授权,授权服务器会调用客户端的后台服务提供的一个回调地址,并在调用过程中将一个授权码返回给客户端。客户端收到授权码后进一步向授权服务器申请令牌。最后,授权服务器核对授权码并向客户端发送访问令牌。</p>
|
||||
<p>这里要注意的是,<strong>通过授权码向授权服务器申请令牌的过程是系统自动完成的,不需要用户的参与,用户需要做的就是在流程启动阶段同意授权</strong>。</p>
|
||||
<p>接下来,我们再来看另一种比较常用的密码模式,其授权流程如下图所示:</p>
|
||||
<p><img src="assets/Cgp9HWDewE2Ab2vhAABPDH7Zxjo001.png" alt="Drawing 5.png" /></p>
|
||||
<p><img src="assets/Cgp9HWDewE2Ab2vhAABPDH7Zxjo001.png" alt="png" /></p>
|
||||
<p>密码模式工作流程图</p>
|
||||
<p>可以看到,密码模式比较简单,也更加容易理解。用户要做的就是提供自己的用户名和密码,然后客户端会基于这些用户信息向授权服务器请求令牌。授权服务器成功执行用户认证操作后将会发放令牌。</p>
|
||||
<p>OAuth2 中的客户端模式和简化模式因为在日常开发过程中应用得不是很多,这里就不详细介绍了。</p>
|
||||
<p>你可能注意到了,虽然 OAuth2 协议解决的是授权问题,但它也应用到了认证的概念,这是因为只有验证了用户的身份凭证,我们才能完成对他的授权。所以说,<strong>OAuth2 实际上是一款技术体系比较复杂的协议,综合应用了信息摘要、签名认证等安全性手段,并需要提供令牌以及背后的公私钥管理等功能</strong>。</p>
|
||||
<h3>OAuth2 协议与微服务架构</h3>
|
||||
<p>对应到微服务系统中,<strong>服务提供者充当的角色就是资源服务器,而服务消费者就是客户端</strong>。所以每个服务本身既可以是客户端,也可以作为资源服务器,或者两者兼之。当客户端拿到 Token 之后,该 Token 就能在各个服务之间进行传递。如下图所示:
|
||||
<img src="assets/CioPOWDewFaAKXrYAABQvvLUy-Q531.png" alt="Drawing 6.png" /></p>
|
||||
<img src="assets/CioPOWDewFaAKXrYAABQvvLUy-Q531.png" alt="png" /></p>
|
||||
<p>OAuth2 协议在服务访问场景中的应用</p>
|
||||
<p>在整个 OAuth2 协议中,最关键的问题就是如何获取客户端授权。就目前主流的微服架构来说,当我们发起 HTTP 请求时,关注的是如何通过 HTTP 协议透明而高效地传递令牌,此时授权码模式下通过回调地址进行授权管理的方式就不是很实用,密码模式反而更加简洁高效。因此,在本专栏中,我们将使用<strong>密码模式</strong>作为 OAuth2 协议授权模式的默认实现方式。</p>
|
||||
<h3>小结与预告</h3>
|
||||
<p>今天我们进入微服务安全性领域展开了探讨,在这个领域中,认证和授权仍然是最基本的安全性控制手段。通过系统分析微服务架构中的认证和授权解决方案,我们引入了 OAuth2 协议,这也是微服务架构体系下主流的授权协议。我们对 OAuth2 协议具备的角色、授权模式以及与微服务架构之间的集成关系做了详细展开。</p>
|
||||
<p>本讲内容总结如下:</p>
|
||||
<p><img src="assets/CioPOWDewF2AG8SOAAGkQKcZcsU075.png" alt="Drawing 7.png" /></p>
|
||||
<p><img src="assets/CioPOWDewF2AG8SOAAGkQKcZcsU075.png" alt="png" /></p>
|
||||
<p>最后给你留一道思考题:你能描述 OAuth2 协议中所具备的四大角色以及四种授权模式吗?欢迎在留言区和我分享你的收获。</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
Reference in New Issue
Block a user