了解OAuth2令牌认证

最新推荐文章于 2024-01-18 11:17:19 发布

dnc8371

最新推荐文章于 2024-01-18 11:17:19 发布

阅读量330

点赞数

文章标签： java http 数据库 jwt session

1.简介

在本教程中，我们将了解OAuth2令牌身份验证 ，以便只有经过身份验证的用户和应用程序才能获得有效的访问令牌，该令牌随后可用于访问服务器上的授权API（在OAuth术语中仅是受保护的资源）。

使用基于令牌的身份验证，通过与服务器的每次交互共享有效的访问令牌，用户/应用程序可以在特定时间段内访问受保护的资源。

2.令牌认证中涉及的事件

使用令牌身份验证，所涉及的事件已在下图中清晰地描述了–

客户端应用程序首先从用户（资源所有者）请求授权授权，因为我们经常会看到弹出授权或拒绝访问其他应用程序数据的授权弹出窗口。例如，Goibibo要求从您的Facebook帐户访问朋友。
一旦用户通过在弹出窗口中单击“授权”进行授权，客户端应用程序（Goibibo）就会收到授权授权。
然后，客户端应用程序（Goibibo）向授权服务器（Facebook）请求访问令牌以及其自身的身份和在上一步中收到的授权授权。
如果客户端应用程序已通过身份验证，并且发现授权授予有效，则授权服务器（由Facebook）提供/向客户端应用程序（Goibibo）发出访问令牌。
然后，客户端应用程序（Goibibo）通过随后将访问令牌传递给资源服务器（由Facebook）来访问受保护的资源（facebook应用程序中的朋友），直到令牌在指定的时间段后过期。

3. OAuth2角色

以下列出了OAuth实现中的委托角色–

1. 资源所有者 –能够授予对受保护资源访问权限的实体。如果您登录Goibibo，并且希望通过您的Facebook帐户访问朋友，则您是资源所有者，需要提供授权授权。
2. 资源服务器 –托管受保护资源的服务器（Facebook），可以使用访问令牌接受和响应受保护资源的请求。这意味着朋友列表是服务器（Facebook）上托管的资源之一，可供其他第三方应用程序（Goibibo）访问。
3. 客户端 –代表资源所有者（用户）并获得其授权的受保护资源请求的应用程序（Goibibo）。我们将所有此类授权授予定义为上下文–
4. 这意味着Gobibo作为客户端应用程序可以访问资源服务器（Facebook）上的管理好友列表。
5. 授权服务器 –根据资源所有者（用户）接收到的客户端应用程序的身份和授权授予，向客户端应用程序提供访问令牌的服务器 。

4.授权补助

OAuth2提供四种类型的授权授予-

4.1授权码

在服务器端应用程序中使用，因此维护了双方的隐私。
最常见的。
基于重定向的流。
用户授权请求通过用户代理（Web浏览器）路由，并且客户端应用程序必须具有足够的能力与用户代理进行交互，并从另一端的授权服务器接收授权代码。

4.2隐式

有点类似于授权码授予类型。
更常用于移动应用程序和Web应用程序。
在客户端，由于授权代码在移交给客户端应用程序之前与用户代理一起存储在本地，因此存在隐私风险。这可以公开给用户设备上的其他应用程序。
不支持刷新令牌。

4.3资源所有者密码凭证

在受信任的应用程序之间使用。
用户（资源所有者）直接与客户端应用程序共享凭据，客户端应用程序在成功验证用户凭据并进一步授权用户访问服务器上的有限资源后，请求授权服务器返回访问令牌。
这是我们将用于演示应用程序的授权授予类型。

4.4客户凭证

当应用程序需要访问其自己的服务帐户段时使用，只有在该服务帐户段的控制下它才能获取资源。
因此，同一应用程序可能还有其他受信任的机密客户端，它们拥有自己的应用程序个人服务帐户，并可能在其控制下拥有不同的受保护资源。
应用程序通过将其凭据，客户端ID和客户端密钥发送到授权服务器来请求访问令牌。

5.令牌存储

涉及的另一个重要组件是令牌存储，它定义了如何存储生成的令牌。默认存储是内存中的实现 ，但是也可以使用其他一些实现，可以根据需要使用它们–

InMemoryTokenStore –令牌存储在服务器内存中，因此存在授权服务器重新启动时丢失令牌的风险。
JwtTokenStore –所有授权和访问授权数据都被编码到令牌本身中，并且此类令牌不会在任何地方持久化。此类令牌使用解码器进行即时验证，并且依赖于JwtAccessTokenConverter 。
JdbcTokenStore –令牌数据存储在关系数据库中。使用此令牌存储，可以安全地重新启动授权服务器。令牌也可以在服务器之间轻松共享，并且可以被吊销。注意，要使用JdbcTokenStore，我们将在类路径中需要“ spring-jdbc”依赖项。

6.刷新令牌流

一旦访问令牌在设计的时间段（根据下面的示例为119）后过期，我们可以使用refresh token重新生成一个新的有效访问令牌。发出原始访问令牌时会附带刷新令牌，如下所示–

{  
   "access_token":"04f12761-501b-415b-8941-52bce532ce60",
   "token_type":"bearer",
   "refresh_token":"fc348b4f-de62-4523-b808-9935b1f2e46f",
   "expires_in":119
}

单击此处导航到官方OAuth2文档