jwt oauth2区别_OAuth2.0 看这篇就够了

最新推荐文章于 2024-03-29 20:02:07 发布

weixin_39847945

最新推荐文章于 2024-03-29 20:02:07 发布

阅读量917

点赞数

文章标签： jwt oauth2区别 oauth2密码方式的登录如何用java代码实现

随着互联网技术的发展，微服务架构已经成为每个互联网公司的标配。伴随着服务粒度的细化，服务的安全和鉴权问题，以及客户端与服务之间的认证问题已经成为必不可少的一项工作。说起认证和鉴权，那怎么少得了 OAuth 2.0 协议呢？

火锅店旁边的照片打印机

这个案例想必大家都遇到过，在商场里面或者餐馆门口会看到一些可以打印照片的设备。想要设备打印出照片那么必须传输照片给设备，但是假如此时由于你的手机设备存储有限，美美的照片被存储在了百度云盘。那么如何让设备获取到你存储在云盘的照片呢？聪明的你肯定已经想到对策了。

1. 账户和密码

这种方式最为简单直接，但是一旦你将账户和密码告诉第三种应用，第三方应用就会无所不能，随意操作你的账户不受你的管控。你唯一能做的就是更改掉旧的密码，这样才能收回你的权限。

2. 开发者钥匙

这种方式需要先在资源提供方申请开发者钥匙，它建立在客户应用和资源方是互相信任的情况下。但是这种方式也会存在开发者钥匙泄露的情况，一旦泄露给不法分子，安全同样会受到威胁。

3. 特殊令牌

这种方式是资源方提供一个令牌给客户应用，通过令牌，客户应用可以访问资源。但是资源方颁发的令牌会受到权限的控制，并且会在有效期终止后自动销毁。

上述特殊令牌的方式即为我们今天即将要讨论的 OAuth 2.0，OAuth 2.0 会解决令牌涉及到的一系列问题。那么 OAuth 2.0 的令牌可以用来解决哪些问题呢？

开放系统间的授权

1. 社交联合登录

想必你在登录一个网站或者应用时候，一定遇到可以通过第三方的应用账户登录的案例。例如你在给一些技术博客做评论的时候需要登录，你又没有该博客的账户，但是你可以通过 GitHub 账户登录然后评论。

2. 开放接口平台

还是 GitHub 的例子，你不但可以直接去 GitHub 的网站上操作账户，你也可以通过 GitHub 提供的开放 API 来操作你的 GitHub 账户。有兴趣可以去了解一下：GitHub API。

微服务安全问题

微服务将应用拆成多个小的应用接口服务，但是各个服务之间的业务难免会有所依赖，此时服务之间的调用也需要有安全的保证。同时客户端的接入也会变得复杂，例如：单页面应用、原生应用、Web App 等。这些应用的接入都需要得到安全保证，OAuth 2.0 可以帮助我们解决这些问题。

内部应用授权

企业内部应用繁多，例如代码平台、应用发布平台、OA 系统等。如果为这些系统分别都创建一个账户，那么这对我们员工来说将是一个灾难，我们要记住每个账户和密码，每个系统都需要分别登录。因此有点规模的企业都需要一套单点登录的服务，我们可以通过 OAuth 2.0 来实现企业级的 SSO（单点登录）服务。

初步认识 OAuth 2.0

如下图所示，OAuth 2.0 中包含四个重要的参与者：资源拥有者、客户应用、受保护资源、授权服务器。下面我们就详细说说 OAuth 2.0 的工作流程，它主要分为以下几个步骤：

首先资源拥有者在客户应用中发起对受保护资源的访问请求。
客户应用向资源服务器发起授权请求。
资源拥有者通过客户应用代理授予客户应用访问资源的权限。
授权服务器得到资源拥有者的指令，向客户应用颁发访问令牌。
客户应用获得受限的权限令牌，访问受保护的资源。

如上几个步骤即为 OAuth 2.0 的主要工作流程。当然其中还有少许细节，客户应用在获得令牌后，第二次访问资源就可以直接使用第一次获取的令牌来访问，无需再次获取。当然令牌也会过期，过期后客户应用需要重新获取授权，这是不是听起来很麻烦呢？OAuth 2.0 支持刷新令牌，即客户应用在令牌过期后，可以直接使用刷新令牌获得新的令牌，这样就省去了重新授权的复杂过程。

OAuth2 到底是什么

定义

上面我们介绍了 OAuth 2.0 的应用场景，以及它的工作流程，是时候来给出 OAuth 2.0 的定义了。

OAuth 2.0 是一个基于令牌 Token 的授权协议，通过它我们可以在不暴露账户和密码的情况下授予客户应用有限的数据访问权限。它解藕了认证和授权，同时它是事实上的安全框架，它能支持服务与服务，App、单页面应用与后端服务等很多应用场景。

授权模式

OAuth 2.0 共有如下四种授权模式，通过下面的任意一种方式，客户应用都可以获得授权令牌来访问受保护的资源。

授权码模式

这种方式是最复杂但也是最安全的方式。资源所有者授予客户应用访问权限后，授权服务器首次发放给客户应用的是一个授权码，随后客户应用在服务器端直接向授权服务器发起兑换授权令牌请求，这样才会获得真正的访问令牌。这种方式虽然复杂，但是你注意到访问令牌是客户应用服务器端代码直接发起的操作，并未通过终端代理，它提高了授权令牌的安全性。一般用于 Web 应用或者原生 App，这样 Token 就不会经过浏览器和 App，这样大大降低了 Token 泄漏的风险。

简化模式

这种方式是授权码模式的一个简化版本，资源所有者授权后，授权服务器直接将令牌发放至代理终端（例如浏览器），省去了授权码的流程。这种方式一般用于没有服务器的单页面应用，因为他们没有服务器端去拿授权码换取 Token。

密码模式

这种方式是资源拥有者直接将账户和密码告诉客户应用，客户应用使用账户和密码去授权服务器换取 Token。这种模式一般应用于企业内部的应用，应用之间是完全可信的，都是第一方应用。

客户端模式

这种方式是最简单的方式，同时它也是最不安全的方式。只要客户端发起请求，授权服务器即授予令牌。因此我们必须保证客户端的安全性，所以这种方式一般应用于企业内部的服务器、服务之间，它们之间无用户参与。

通过对四种工作模式的介绍，想必你已经明白了它们之间的区别，同时你也知道了它们具体的应用场景。最后我们将模式的选择总结如下图示：

参照如上选择流程选择对应的应用模式，相信你已经掌握了如何选择合适的模式。

本文为我在 GitChat 的付费文章节选 OAuth2.0 看这篇就够了，完整内容目录如下： 1. OAuth2.0 应用场景。 2. OAuth2.0 工作原理。 3. OAuth2.0 的几种工作模式介绍。 4. OAuth2.0 的工作模式选择。 5. Spring Security OAuth2.0 架构设计。 6. Spring Security OAuth2.0 应用实战。 7. JWT 工作原理。 8. JWT 应用实战。 9. 移动端 App 如何接入 OAuth2.0。 10. Spring Social 社交登录案例。 11. 微服务安全架构展望

欢迎有需要的小伙伴订阅，另外作者有十个免费名额分享，使用微信打开免费链接即可获取。

公众号每天输出优质原创技术文章，欢饮关注一起来探讨。