Keycloak-OpenId Connect访问类型

Question

我想针对仅使用keycloak OIDC承载当前受保护的node-js（两个应用程序都属于同一领域）对旧版Java（6）应用程序进行身份验证。

有人告诉我使用keycloak-authz-client库解析密钥库OIDC JSON，如下所示 { "realm": "xxx", "realm-public-key": "fnzejhbfbhafbazhfzafazbfgeuizrgyez...", "bearer-only": true, "auth-server-url": "http://xxx:80/auth", "ssl-required": "external", "resource": "resourceName" }

但是，keycloak Java客户端需要Java 8，而我当前的运行时是jre6。重新编译包含传递依赖项的库似乎不是一个好主意，我最终使用keycloak oauth2 REST端点。

据我所知，oauth2我将使用client_credentials流在应用程序初始化时与access_token交换一次客户端机密，并在过期时进行刷新/更新。

进入keycloak文档：

访问类型

这定义了OIDC客户端的类型。

机密

机密访问类型适用于需要执行浏览器登录并在将访问代码转换为访问令牌时需要客户端密码的服务器端客户端（有关更多详细信息，请参阅OAuth 2.0规范中的“访问令牌请求”）。此类型应用于服务器端应用程序。上市

公共访问类型适用于需要执行浏览器登录的客户端。使用客户端应用程序无法保持机密安全。相反，通过为客户端配置正确的重定向URI来限制访问非常重要。仅持票人

仅承载访问类型意味着应用程序仅允许承载令牌请求。如果启用此功能，则该应用程序无法参与浏览器登录。

似乎confidential访问类型是一种适合我的需求（应该用于服务器端应用程序），但是我不知道它与浏览器登录的关系（这与使用第三方身份提供商进行身份验证有关） facebook和co）。

该confidential客户端设置也需要URI的浏览器有效的重定向会成功登录或lagout后重定向到。由于我要认证的客户端是一个应用程序，因此我不明白这一点。

一般来说，我不了解整个访问类型。它是否仅与客户端有关，还是与资源所有者有关（我的node.js应用程序是否仅在现有客户端使用此访问类型时才保留在承载上？它会使用通过client_credentials流获得的access_token接受承载认证吗？我猜想是将）。

有人可以弄清楚keycloak OIDC访问类型以及我做错了哪里吗？

使用keycloak将旧应用程序的访问权委派给另一个应用程序的某些资源（不限于特定用户资源）的正确方法是什么？

Answer 1

您混淆了Client Types和的 OAuth 2.0 概念Grants。这些是不同但相互关联的概念。前者指的是应用程序架构，而后者指的是处理特定授权/身份验证用例的适当授权。

人们选择并组合这些选项；第一个选择客户端类型（例如 public，，confidential），然后选择授权（例如， Authorization code flow）。两种客户端类型共享一些相同的授权，但需要注意的是，客户confidential端在执行身份验证/授权授权期间还需要提供客户端密钥。

来自Oauth 2.0 规范：

   OAuth defines two client types, based on their ability to
   authenticate securely with the authorization server (i.e., ability to
   maintain the confidentiality of their client credentials):

   confidential
      Clients capable of maintaining the confidentiality of their
      credentials (e.g., client implemented on a secure server with
      restricted access to the client credentials), or capable of secure
      client authentication using other means.

   public
      Clients incapable of maintaining the confidentiality of their
      credentials (e.g., clients executing on the device used by the
      resource owner, such as an installed native application or a web
      browser-based application), and incapable of secure client
      authentication via any other means.

正如人们所理解的，它client type指的是应用程序架构的类型。为什么需要这些类型？答案是添加额外的安全层。

让我们看一下 的例子Authorization Code Grant。通常流程如下：

• 用户访问应用程序；
• 用户被重定向到 Keycloak 登录页面；
• 用户验证自己的身份；
• Keycloak检查用户名和密码，如果正确，则向应用程序发送回授权码；
• 应用程序接收该代码并调用 Keycloak 以将代码交换为令牌。

该流程的“安全问题”之一是代码与令牌的交换发生在前端通道上，由于浏览器的性质，黑客很容易拦截该代码并在真正的应用程序之前将其交换为令牌它。有一些方法可以减轻这种情况，但这超出了这个问题的范围。

现在，如果您的应用程序是单页应用程序，那么它无法安全地存储机密，因此我们必须使用public客户端类型。但是，如果应用程序有一个可以安全存储客户端机密的后端，那么我们可以使用机密客户端。

因此，对于相同的流程（即 Authorization Code Grant），可以通过使用机密客户端使其更加安全。这是因为应用程序现在还必须向 Keycloak 发送客户端密钥，这发生在后端通道上，它比前端通道更安全。

使用 keycloak 将旧应用程序的访问权限委托给另一个应用程序的某些资源（不限于特定用户的资源）的正确方法是什么？

正确的授权是使用所谓的Client Credential Grant：

4.4. 客户凭证授予

当客户端请求 访问其 控制下的受保护资源或先前已与授权服务器安排的其他资源所有者的资源
时，客户端可以仅使用其客户端凭据（或其他支持的身份验证方式）请求访问令牌（其方法超出了本规范的范围）。

由于此授权使用客户端凭据（例如客户端密钥），因此您只能在选择机密作为客户端类型时才能使用它。