使用Postman访问Keycloak endpoints-编程知识-白鹭情

1.简介

在本文中，我们将快速回顾OAuth 2.0，OpenID和Keycloak。之后，我们将学习Keycloak REST API以及如何在Postman中调用它们。

2. OAuth 2.0

OAuth 2.0是一种授权框架，可让经过身份验证的用户通过令牌向第三方授予访问权限。令牌通常限于生命周期有限的某些范围。因此，它是替代用户凭据的安全方法。

OAuth 2.0包含四个主要组件：

资源所有者–拥有受保护资源或数据的最终用户或系统
资源服务器–该服务通常通过基于HTTP的API公开受保护的资源
客户端–代表资源所有者调用受保护的资源
授权服务器–颁发OAuth 2.0令牌，并在对资源所有者进行身份验证后将其传递给客户端

OAuth 2.0是具有一些标准流程的协议，但是我们对授权服务器组件特别感兴趣。

3. OpenID C0nnect

OpenID Connect 1.0 （OIDC）建立在OAuth 2.0的基础上，用于向协议添加身份管理层。因此，它允许客户端验证最终用户的身份并通过标准OAuth 2.0流访问基本配置文件信息。 OIDC向OAuth 2.0引入了一些标准范围，例如openid ， profile和email 。

4. Keycloak作为授权服务器

JBoss已将Keycloak开发为基于Java的开源身份和访问管理解决方案。除了同时支持OAuth 2.0和OIDC，它还提供身份代理，用户联合和SSO等功能。

我们可以将Keycloak用作带有管理控制台的独立服务器，也可以将其嵌入Spring应用程序中。一旦我们以以下两种方式之一运行Keycloak，我们就可以尝试端点。

5. Keycloak Endpoints

Keycloak为OAuth 2.0流提供了各种REST端点。

要将这些端点与Postman一起使用，让我们开始创建一个名为“ Keycloak ”的环境。然后，我们为Keycloak授权服务器URL，领域，OAuth 2.0客户端ID和客户端密码添加一些键/值条目：

使用邮递员访问Keycloak端点

然后，让我们创建一个集合，在其中可以组织我们的Keycloak测试。现在，我们准备探索可用的端点。

5.1。 OpenID配置端点

配置端点就像根目录。它返回所有其他可用的端点，支持的范围和声明以及签名算法。

让我们在邮递员中创建一个请求： {{server}} / auth / realms / {{realm}} /。众所周知/ openid-configuration。邮递员在运行时从所选环境中设置{{server}}和{{realm}}的值：

使用邮递员访问Keycloak端点

然后我们执行请求，如果一切顺利，我们将收到响应：

{

 "issuer": "http://localhost:8083/auth/realms/baeldung",

 "authorization_endpoint": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/auth",

 "token_endpoint": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/token",

 "token_introspection_endpoint": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/token/introspect",

 "userinfo_endpoint": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/userinfo",

 "end_session_endpoint": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/logout",

 "jwks_uri": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/certs",

 "check_session_iframe": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/login-status-iframe.html",

 "grant_types_supported": [...],

 ...

 "registration_endpoint": "http://localhost:8083/auth/realms/baeldung/clients-registrations/openid-connect",

 ...

 "introspection_endpoint": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/token/introspect"

 }

如前所述，我们可以在响应中看到所有可用的端点，例如“ authorization_endpoint ”，“ token_endpoint ”等。

此外，响应中还有其他有用的属性。例如，我们可以计算出从“支持所有类型的补助grant_types_supported ”或所有“支持范围scopes_supported ”。

5.2。授权端点

让我们继续负责OAuth 2.0授权代码流的授权端点的旅程。在OpenID配置响应中，它可以作为“authorization_endpoint”使用。

Endpoints是：

{{server}} / auth / realms / {{realm}} / protocol / openid-connect / auth？response_type = code＆client_id = jwtClient

此外，此端点接受scope和redirect_uri作为可选参数。

我们不会在Postman中使用此端点。相反，我们通常会通过浏览器启动授权代码流。如果没有活动的登录cookie，则Keycloak会将用户重定向到登录页面。最后，授权代码将传递到重定向URL。

让我们转到下一步，看看如何获取访问令牌。

5.3。令牌端点

令牌端点允许我们检索访问令牌，刷新令牌或ID令牌。 OAuth 2.0支持不同的授予类型，例如authorization_code ， refresh_token,或password.

令牌端点是： {{server}} / auth / realms / {{realm}} / protocol / openid-connect / token

但是，每种授权类型都需要一些专用的表单参数。

首先让我们测试令牌端点，以获取用于授权代码的访问令牌。我们必须在请求正文中传递以下表单参数： client_id ， client_secret ， grant_type ， code和redirect_uri 。令牌端点还接受scope作为可选参数：

使用邮递员访问Keycloak端点

此外，如果我们要绕过授权码流程，则选择password授予类型.这里我们需要用户凭据，因此当我们的网站或应用程序上具有内置登录页面时，可以使用此流程。

让我们创建一个邮递员请求，并在正文中传递格式参数client_id ， client_secret ， grant_type ， username和password ：

使用邮递员访问Keycloak端点

在执行此请求之前，我们必须将username和password变量添加到Postman的环境键/值对中。

另一种有用的授予类型是refresh_token 。当我们从上次调用令牌端点时获得有效的刷新令牌时，可以使用此方法。刷新令牌流需要参数client_id ， client_secret ， grant_type和refresh_token 。

我们需要响应access_token来测试其他端点。为了加快Postman的测试速度，我们可以在令牌端点请求的“ Tests部分中编写脚本：

var jsonData = JSON.parse(responseBody);

 postman.setEnvironmentVariable("refresh_token", jsonData.refresh_token);

 postman.setEnvironmentVariable("access_token", jsonData.access_token);

使用邮递员访问Keycloak端点

5.4。用户信息Endpoints

当我们具有有效的访问令牌时，我们可以从用户信息端点检索用户配置文件数据。

用户信息端点位于以下位置： {{server}} / auth / realms / {{realm}} / protocol / openid-connect / userinfo

让我们为其创建一个邮递员请求，并在Authorization标头中传递访问令牌：

使用邮递员访问Keycloak端点

然后我们执行请求。这是成功的响应：

{

 "sub": "a5461470-33eb-4b2d-82d4-b0484e96ad7f",

 "preferred_username": "[email protected]",

 "DOB": "1984-07-01",

 "organization": "baeldung"

 }

5.5。令牌自省端点

如果资源服务器需要验证访问令牌是否处于活动状态或需要更多有关它的元数据，尤其是对于不透明的访问令牌，则令牌自省端点就是答案。在这种情况下，资源服务器将自省过程与安全配置集成在一起。

我们称Keycloak的自省端点： {{server}} / auth / realms / {{realm}} / protocol / openid-connect / token / introspect

让我们在Postman中创建一个自省请求，然后将client_id ， client_secret和token作为表单参数传递：

使用邮递员访问Keycloak端点

如果access_token有效，则我们有响应：

{

 "exp": 1601824811,

 "iat": 1601824511,

 "jti": "d5a4831d-7236-4686-a17b-784cd8b5805d",

 "iss": "http://localhost:8083/auth/realms/baeldung",

 "sub": "a5461470-33eb-4b2d-82d4-b0484e96ad7f",

 "typ": "Bearer",

 "azp": "jwtClient",

 "session_state": "96030af2-1e48-4243-ba0b-dd4980c6e8fd",

 "preferred_username": "[email protected]",

 "email_verified": false,

 "acr": "1",

 "scope": "profile email read",

 "DOB": "1984-07-01",

 "organization": "baeldung",

 "client_id": "jwtClient",

 "username": "[email protected]",

 "active": true

 }

但是，如果我们使用无效的访问令牌，则响应为：

{

 "active": false

 }

六，结论

在本文中，使用正在运行的Keycloak服务器，我们为授权，令牌，用户信息和自省端点创建了邮递员请求。