理解最重要的端点是 已知的 配置端点。它列出了红帽构建的 Keycloak 中与 OpenID Connect 实现相关的端点和其他配置选项。端点是：

/realms/{realm-name}/.well-known/openid-configuration

要获取完整的 URL，请为红帽构建的 Keycloak 添加基本 URL，并将 {realm-name} 替换为您的域的名称。例如：

http://localhost:8080/realms/master/.well-known/openid-configuration

有些 RP 库从这个端点检索所有必需的端点，但对于您可能需要单独列出端点的其他人，您可能需要单独列出端点。

/realms/{realm-name}/protocol/openid-connect/auth

/realms/{realm-name}/protocol/openid-connect/token

/realms/{realm-name}/protocol/openid-connect/userinfo

/realms/{realm-name}/protocol/openid-connect/logout

/realms/{realm-name}/protocol/openid-connect/certs

/realms/{realm-name}/protocol/openid-connect/token/introspect

/realms/{realm-name}/clients-registrations/openid-connect

/realms/{realm-name}/protocol/openid-connect/revoke

/realms/{realm-name}/protocol/openid-connect/auth/device

/realms/{realm-name}/protocol/openid-connect/ext/ciba/auth

Authorization Code 流将用户代理重定向到红帽构建的 Keycloak。用户通过红帽构建的 Keycloak 成功进行身份验证后，会创建一个授权代码，用户代理将重新重定向到应用程序。然后，应用程序使用授权代码及其凭证从红帽构建的 Keycloak 获取访问令牌、刷新令牌和 ID 令牌。

该流程面向 Web 应用程序，但对于原生应用程序（包括移动应用程序）也推荐在什么地方嵌入用户代理。

更多详情请参阅 OpenID Connect 规格中的 授权代码流。

Implicit 流的工作方式与授权代码流类似，但不返回授权代码，而是返回访问令牌和 ID 令牌。这种方法减少了额外的调用来交换访问令牌的授权代码。但是，它不包括 Refresh Token。这会产生允许长时间过期的访问令牌；但是，这种方法并不实际，因为它很难使这些令牌无效。另外，您可以在初始访问令牌过期后需要新的重定向来获取新的访问令牌。如果应用程序只想验证用户和处理注销自身，则 Implicit 流很有用。

您可以使用返回 Access Token 和 Authorization Code 的混合流。

需要注意的一件事情是，Implicit 流和混合流都有潜在的安全风险，因为访问令牌可能会通过 Web 服务器日志和浏览器历史记录泄露。对于访问令牌，您可以使用简短的过期时间来缓解这个问题。

如需了解更多详细信息，请参阅 OpenID Connect 规格中的 Implicit 流。

在 Red Hat build of Keycloak 中，资源所有者密码凭证（称为 Direct Grant ）允许交换令牌的用户凭证。除非至关重要，否则不建议使用这个流。此流可能有用的示例是传统应用程序和命令行界面。

使用这个流的限制包括：

要使客户端被允许使用 Resource Owner Password Credentials grant，客户端必须启用 Direct Access Grants Enabled 选项。

此流不包含在 OpenID Connect 中，而是是 OAuth 2.0 规范的一部分。

如需了解更多详细信息，请参阅 OAuth 2.0 规格中的 Resource Owner Password Credentials Grant 章节。

curl \
  -d "client_id=myclient" \
  -d "client_secret=40cc097b-2a57-4c17-b36a-8fdf3fc2d578" \
  -d "username=user" \
  -d "password=password" \
  -d "grant_type=password" \
  "http://localhost:8080/realms/master/protocol/openid-connect/token"

当客户端（应用程序和服务）希望代表自己获取访问权限时，会使用客户端凭证，而不是代表用户获得访问权限。例如，这些凭据对于一般对系统而非特定用户应用更改的后台服务非常有用。

红帽构建的 Keycloak 支持客户端通过 secret 或公钥/私钥进行身份验证。

此流不包含在 OpenID Connect 中，而是是 OAuth 2.0 规范的一部分。

如需了解更多详细信息，请参阅 OAuth 2.0 规格中的 客户端 凭证授予一章。

在互联网连接的设备中运行的客户端使用设备授权授予功能，或者缺少合适的浏览器。应用程序请求红帽构建 Keycloak，一个设备代码和用户代码。红帽构建的 Keycloak 创建一个设备代码和用户代码。红帽构建的 Keycloak 会向应用程序返回包括设备代码和用户代码的响应。应用为用户提供用户代码和验证 URI。用户访问验证 URI 以供使用其他浏览器进行身份验证。应用程序会重复轮询红帽构建的 Keycloak，直到红帽构建的 Keycloak 完成用户授权。如果完成用户身份验证，则应用会获取设备代码。应用程序使用设备代码及其凭证从红帽构建的 Keycloak 获取访问令牌、刷新令牌和 ID 令牌。

如需了解更多详细信息，请参阅 OAuth 2.0 设备授权规格。

客户端发起的背景通道身份验证授予供希望启动身份验证流的客户端使用，方法是直接与 OpenID 提供程序通信，而无需通过 OAuth 2.0 授权代码授权代码等用户浏览器重定向。

来自红帽构建的 Keycloak 的客户端请求一个 auth_req_id，用于标识客户端发出的身份验证请求。红帽构建的 Keycloak 创建 auth_req_id。

收到这个 auth_req_id 后，此客户端会重复轮询红帽构建的 Keycloak，以获取来自红帽构建的 Keycloak 的访问令牌、刷新令牌和 ID 令牌，以返回 auth_req_id，直到用户被验证为止。

如果客户端使用 ping 模式，则不需要重复轮询令牌端点，但可以等待红帽构建的 Keycloak 发送到指定的客户端通知端点。客户端通知端点可在红帽构建的 Keycloak 管理控制台中配置。CIBA 规范中描述了客户端通知端点合同详情。

如需了解更多详细信息，请参阅 OpenID Connect Client Initiated Backchannel Authentication Flow 规格。

另请参阅 Red Hat build of Keycloak 文档的其他位置，如本指南的 backchannel Authentication Endpoint 和 Server Administration Guide 中的 Client Initiated Backchannel Authentication Grant 部分。有关 FAPI CIBA 合规性的详情，请查看 本指南的 FAPI 部分。

红帽构建的 Keycloak 不包括 Red Hat JBoss Enterprise Application Platform 的任何适配器。但是，对于部署到 Red Hat JBoss Enterprise Application Platform 的现有应用程序有替代方案。

红帽构建的 Keycloak 不包括 Spring Boot 的任何适配器。但是，使用 Spring Boot 构建的现有应用程序有替代方案。

Spring Security 为 OAuth 2 和 OpenID Connect 提供全面的支持。如需更多信息，请参阅 Spring 安全文档。

另外，对于 Spring Boot 2.x，Red Hat Single Sign-On 7.6 的 Spring Boot 适配器可与 Red Hat build of Keycloak 服务器结合使用。如需更多信息，请参阅 Red Hat Single Sign-On 文档。

适配器以多种方式发布，但我们建议您从 NPM 安装 keycloak-js 软件包：

npm install keycloak-js

另外，该库可以直接从位于 /js/keycloak.js 的 Keycloak 服务器的红帽构建中检索，也可以作为 ZIP 存档分发。但是，我们考虑从 Keycloak 服务器直接包含适配器已被弃用，这个功能可能会在以后被删除。

要考虑使用客户端侧应用的一个重要事项是客户端必须是公共客户端，因为无法将客户端凭据存储在客户端侧应用中。考虑到这一点，请确保您为客户端配置的重定向 URI 正确且尽量具体。

要使用适配器，请在红帽构建的 Keycloak 管理控制台中为应用程序创建一个客户端。通过将客户端身份验证切换为 Off 在 Capability 配置页面中使客户端变为 Off。

您还需要配置 Valid Redirect URI 和 Web Origins。尽可能具体这样做可能会导致安全漏洞。

以下示例演示了如何初始化适配器。确保将传递给 Keycloak 构造器的选项替换为您配置的客户端。

import Keycloak from 'keycloak-js';

const keycloak = new Keycloak({
    url: 'http://keycloak-server${kc_base_path}',
    realm: 'myrealm',
    clientId: 'myapp'
});

try {
    const authenticated = await keycloak.init();
    console.log(`User is ${authenticated ? 'authenticated' : 'not authenticated'}`);
} catch (error) {
    console.error('Failed to initialize adapter:', error);
}

要进行身份验证，您需要调用 登录 功能。有两个选项以使适配器自动验证。您可以将 login-required 或 check-sso 传递给 init （） 函数。

您可以配置一个静默的 check-sso 选项。启用这个功能后，您的浏览器不会对红帽构建的 Keycloak 服务器执行完全重定向到您的应用程序，但此操作将在隐藏的 iframe 中执行。因此，您的应用程序资源只会由浏览器加载并解析一次，即在应用程序被初始化时，而不是在从红帽构建的 Keycloak 重新到应用程序后再次解析。对于 SPAs (Single Page Applications)，此方法特别有用。

要启用 silent check-sso，您可以在 init 方法中提供 silentCheckSsoRedirectUri 属性。确保此 URI 是应用程序中的有效端点；它必须配置为红帽构建的 Keycloak 管理控制台中的客户端的有效重定向：

keycloak.init({
    onLoad: 'check-sso',
    silentCheckSsoRedirectUri: `${location.origin}/silent-check-sso.html`
});

在成功检查身份验证状态并从红帽 Keycloak 服务器检索令牌后，silent check-sso redirect uri 会加载到 iframe 中。它没有其他任务，而不是将接收的令牌发送到主应用程序，且应类似如下：

<!doctype html>
<html>
<body>
    <script>
        parent.postMessage(location.href, location.origin);
    </script>
</body>
</html>

请记住，此页面必须由您的应用程序在 silentCheckSsoRedirectUri 中的指定位置提供，且不是 适配器的一部分。

要启用 login-required 在Load 到 login-required，并传递给 init 方法：

keycloak.init({
    onLoad: 'login-required'
});

在经过身份验证后，应用程序可以通过在 Authorization 标头中包含 bearer 令牌来向红帽构建的 Keycloak 安全的 RESTful 服务发出请求。例如：

async function fetchUsers() {
    const response = await fetch('/api/users', {
        headers: {
            accept: 'application/json',
            authorization: `Bearer ${keycloak.token}`
        }
    });

    return response.json();
}

请记住，访问令牌默认有一个较短的生命周期过期，因此您可能需要在发送请求前刷新访问令牌。您可以通过调用 updateToken （） 方法来刷新此令牌。这个方法会返回 Promise，它可让您仅在成功刷新令牌时轻松调用该服务，并在用户未刷新时向用户显示一个错误。例如：

try {
    await keycloak.updateToken(30);
} catch (error) {
    console.error('Failed to refresh token:', error);
}

const users = await fetchUsers();

默认情况下，适配器会创建一个隐藏的 iframe，用于检测是否发生 Single-Sign Out。这个 iframe 不需要任何网络流量。相反，通过查看特殊的状态 cookie 来检索状态。通过在传递给 init （） 方法的选项中设置 checkLoginIframe: false 来禁用此功能。

您不应该直接查看此 Cookie。其格式可能会改变，它还与红帽构建的 Keycloak 服务器的 URL 关联，而不是您的应用程序。

默认情况下，适配器使用 Authorization Code 流。

在这个版本中，红帽构建的 Keycloak 服务器会将授权代码而不是身份验证令牌返回给应用程序。JavaScript 适配器在浏览器重定向到应用程序后交换访问令牌 的代码和 刷新令牌。

红帽构建的 Keycloak 还支持 Implicit 流，在通过红帽构建的 Keycloak 身份验证成功后立即发送访问令牌。此流的性能可能比标准流更强，因为不存在额外的请求来交换令牌的代码，但在访问令牌过期时有影响。

但是，在 URL 片段中发送访问令牌可能是安全漏洞。例如，可以通过 Web 服务器日志和浏览器历史记录来泄漏令牌。

要启用隐式流，您可以在红帽构建的 Keycloak 管理控制台中为客户端启用 Implicit Flow Enabled 标志。您还将参数 流 传递值为 implicit 到 init 方法：

keycloak.init({
    flow: 'implicit'
})

请注意，只提供访问令牌，且没有刷新令牌。这意味着，一旦访问令牌已过期，应用程序必须重新重定向到红帽构建的 Keycloak，以获取新的访问令牌。

红帽构建的 Keycloak 还支持 混合 流。

此流要求客户端在管理控制台中 同时启用 了标准流和 Implicit 流。然后，红帽构建的 Keycloak 服务器会将代码和令牌发送到您的应用程序。访问令牌可以在交换代码以访问和刷新令牌时使用。与隐式流类似，混合流程非常适合性能，因为访问令牌会立即可用。但是，令牌仍然在 URL 中发送，前面提到的安全漏洞可能仍然适用。

混合流的一个优点是，刷新令牌可供应用程序使用。

对于混合流，您需要将值为 hybrid 的参数 流 传递给 init 方法：

keycloak.init({
    flow: 'hybrid'
});

红帽构建的 Keycloak 支持使用 Apache Cordova 开发的混合移动应用程序。适配器具有两种模式： cordova 和 cordova-native ：

默认为 cordova，如果没有显式配置适配器类型，且存在 window.cordova，则适配器会自动选择它。登录时，它会打开一个 InApp Browser，允许用户与红帽构建的 Keycloak 交互，随后通过重定向到 http://localhost 来返回到应用程序。由于此行为，您可以在管理控制台的客户端配置部分中将此 URL 列为有效的 redirect-uri。

虽然此模式易于设置，但它也有一些缺点：

使用这个示例应用程序帮助您开始： https://github.com/keycloak/keycloak/tree/master/examples/cordova

另一种模式是'cordova-native'，它采用不同的方法。它使用系统的浏览器打开登录页面。用户通过身份验证后，浏览器将使用特殊 URL 重新重定向到应用。在这里，红帽构建的 Keycloak 适配器可以通过从 URL 读取代码或令牌来完成登录。

您可以通过将 adapter 类型 cordova-native 传递给 init （） 方法来激活原生模式：

keycloak.init({
    adapter: 'cordova-native'
});

这个适配器需要额外的插件：

链接到每个平台上的应用程序的技术详情会有所不同，需要特殊设置。有关进一步说明，请参阅 deeplinks 插件文档中的 Android 和 iOS 部分。

开放应用程序有不同类型的链接：* 自定义方案，如 myapp://login 或 android-app://com.example.myapp/https/example.com/login * Universal Links (iOS)）/ Deep Links (Android)。虽然前者更容易设置并倾向于更可靠工作，但后者会提供额外的安全性，因为它们是唯一的，且只有域的所有者可以注册它们。custom-URL 在 iOS 上已弃用。为获得最佳可靠性，我们建议您将通用链接与使用 custom-url 链接的回退站点结合使用。

另外，我们建议以下步骤提高与适配器的兼容性：

<preference name="AndroidLaunchMode" value="singleTask" />

有一个示例 app，显示如何使用 native-mode: https://github.com/keycloak/keycloak/tree/master/examples/cordova-native

在某些情况下，您可能需要在不受默认支持的环境中运行适配器，如 Capacitor。要在这些环境中使用 JavasScript 客户端，您可以传递自定义适配器。例如，第三方库可以提供这样的适配器，以便可以可靠地运行适配器：

import Keycloak from 'keycloak-js';
import KeycloakCapacitorAdapter from 'keycloak-capacitor-adapter';

const keycloak = new Keycloak();

keycloak.init({
    adapter: KeycloakCapacitorAdapter,
});

这个特定软件包不存在，但它提供了一个用户最好将适配器传递给客户端的示例。

也可以自行实现适配器，因此您必须实现 KeycloakAdapter 接口中描述的方法。例如，以下 TypeScript 代码确保正确实施所有方法：

import Keycloak, { KeycloakAdapter } from 'keycloak-js';

// Implement the 'KeycloakAdapter' interface so that all required methods are guaranteed to be present.
const MyCustomAdapter: KeycloakAdapter = {
    login(options) {
        // Write your own implementation here.
    }

    // The other methods go here...
};

const keycloak = new Keycloak();

keycloak.init({
    adapter: MyCustomAdapter,
});

另外，您可以通过省略类型信息来在没有 TypeScript 的情况下执行此操作，但请确保正确实施接口将完全保留。

在最新版本的某些浏览器中，会应用各种 Cookie 策略，以防止由第三方跟踪用户，如 Chrome 中的 SameSite 或完全阻止第三方 Cookie。这些策略可能会变得更严格并被其他浏览器随时间采用。最终，第三方上下文中的 Cookie 可能会完全不受支持，并由浏览器阻止。因此，受影响的适配器功能可能会最终被弃用。

适配器依赖于 Session Status iframe、静默 check-sso 以及部分常规（非静默） check-sso。这些功能有有限的功能，或者根据浏览器对 Cookie 的限制而完全禁用。适配器会尝试检测此设置并相应地响应。

假设您已安装了 Node.js，请为您的应用程序创建一个文件夹：

mkdir myapp && cd myapp

使用 npm init 命令为您的应用程序创建 package.json。现在，在依赖项列表中添加红帽构建的 Keycloak 连接适配器：

    "dependencies": {
        "keycloak-connect": "file:keycloak-connect-22.0.11+redhat-00001.tgz"
    }

在项目的根目录中，创建一个名为 server.js 的文件并添加以下代码：

    const session = require('express-session');
    const Keycloak = require('keycloak-connect');

    const memoryStore = new session.MemoryStore();
    const keycloak = new Keycloak({ store: memoryStore });

安装 express-session 依赖项：

    npm install express-session

要启动 server.js 脚本，请在 package.json 的 'scripts' 部分添加以下内容：

    "scripts": {
        "test": "echo \"Error: no test specified\" && exit 1",
        "start": "node server.js"
    },

现在，我们可以使用以下命令运行服务器：

    npm run start

默认情况下，这将找到一个名为 keycloak.json 的文件，以及应用程序的主可执行文件（在根文件夹上），以初始化红帽构建的 Keycloak 特定设置，如公钥、域名、各种 URL。

在这种情况下，红帽构建的 Keycloak 部署需要访问红帽构建的 Keycloak 管理控制台。

请访问有关如何使用 Podman 或 Docker部署红帽构建的 Keycloak 管理控制台的链接

现在，我们已准备好通过访问 Red Hat build of Keycloak Admin Console → client (left sidebar)→ 选择您的 client → Installation → Format Option → Keycloak OIDC JSON → Download 。

将下载的文件粘贴到我们的项目的根目录上。

使用此方法进行实例化会导致所有合理的默认值都被使用。另外，也可以提供配置对象，而不是 keycloak.json 文件：

    const kcConfig = {
        clientId: 'myclient',
        bearerOnly: true,
        serverUrl: 'http://localhost:8080',
        realm: 'myrealm',
        realmPublicKey: 'MIIBIjANB...'
    };

    const keycloak = new Keycloak({ store: memoryStore }, kcConfig);

应用程序也可以使用以下方法将用户重定向到首选身份提供程序：

    const keycloak = new Keycloak({ store: memoryStore, idpHint: myIdP }, kcConfig);

    const session = require('express-session');
    const memoryStore = new session.MemoryStore();

    // Configure session
    app.use(
      session({
        secret: 'mySecret',
        resave: false,
        saveUninitialized: true,
        store: memoryStore,
      })
    );

    const keycloak = new Keycloak({ store: memoryStore });

    const keycloak = new Keycloak({ scope: 'offline_access' });

实例化后，将中间件安装到支持连接的应用程序中：

为此，首先需要安装 Express：

    npm install express

然后，在项目中需要 Express，如下所示：

    const express = require('express');
    const app = express();

并通过在以下代码中添加并在 Express 中配置 Keycloak 中间件：

    app.use( keycloak.middleware() );

最后，通过将以下代码添加到 main.js，使服务器设置为侦听端口 3000 上的 HTTP 请求：

    app.listen(3000, function () {
        console.log('App listening on port 3000');
    });

如果应用程序在终止 SSL connection Express 的代理后面运行，则必须根据 代理指南后面的表达 进行配置。使用不正确的代理配置可能会导致生成无效的重定向 URI。

配置示例：

    const app = express();

    app.set( 'trust proxy', true );

    app.use( keycloak.middleware() );

    app.get( '/complain', keycloak.protect(), complaintHandler );

    app.get( '/special', keycloak.protect('special'), specialHandler );

使用不同应用程序的应用程序角色 保护资源 ：

    app.get( '/extra-special', keycloak.protect('other-app:special'), extraSpecialHandler );

使用 realm 角色保护资源：

    app.get( '/admin', keycloak.protect( 'realm:admin' ), adminHandler );

    app.get('/apis/me', keycloak.enforcer('user:profile'), userProfileHandler);

keycloak-enforcer 方法在两个模式下运行，具体取决于 response_mode 配置选项的值。

    app.get('/apis/me', keycloak.enforcer('user:profile', {response_mode: 'token'}), userProfileHandler);

如果将 response_mode 设置为 令牌，则权限代表发送到应用程序的 bearer 令牌代表从服务器获得。在这种情况下，Keycloak 会发布一个新的访问令牌，其权限由服务器授予。如果服务器没有响应具有预期权限的令牌，请求将被拒绝。使用此模式时，您应该能够从请求获取令牌，如下所示：

    app.get('/apis/me', keycloak.enforcer('user:profile', {response_mode: 'token'}), function (req, res) {
        const token = req.kauth.grant.access_token.content;
        const permissions = token.authorization ? token.authorization.permissions : undefined;

        // show user profile
    });

当应用程序使用会话且您想要从服务器缓存以前的决策时，首选这种模式，并自动处理刷新令牌。这个模式对于充当客户端和服务器的应用程序特别有用。

如果将 response_mode 设为 权限 （默认模式），服务器只返回授予的权限列表，而不发出新的访问令牌。除了不发布新令牌外，此方法还通过 请求 公开服务器授予的权限，如下所示：

    app.get('/apis/me', keycloak.enforcer('user:profile', {response_mode: 'permissions'}), function (req, res) {
        const permissions = req.permissions;

        // show user profile
    });

无论正在使用中的 response_mode，keycloak.enforcer 方法都将首先尝试检查发送到应用程序的 bearer 令牌中的权限。如果 bearer 令牌已经获得预期权限，则不需要与服务器交互来获取决策。当您的客户端能够在访问受保护的资源前从具有所需权限的服务器获取访问令牌时，这特别有用，因此它们可以使用 Keycloak 授权服务提供的一些功能，如增量授权，并在 keycloak.enforcer 强制访问资源时从服务器获取访问令牌。

默认情况下，策略 enforcer 将使用定义为应用程序（例如，通过 keycloak.json）定义的 client_id 来引用支持 Keycloak 授权服务的 Keycloak 中的客户端。在这种情况下，客户端不能是公共的，表示它实际上是一个资源服务器。

如果您的应用程序同时充当公共客户端(frontend)和资源服务器(backend)，您可以使用以下配置引用 Keycloak 中的不同客户端，以及您要强制执行的策略：

      keycloak.enforcer('user:profile', {resource_server_id: 'my-apiserver'})

建议您在 Keycloak 中使用不同的客户端来代表您的前端和后端。

如果您使用 Keycloak 授权服务启用了您要保护的应用程序，且您在 keycloak.json 中定义客户端凭证，您可以将其他声明推送到服务器，并将其提供给您的策略，以便做出决策。为此，您可以定义一个 claims 配置选项，它需要一个会返回一个带有您要推送的声明的 JSON 的函数：

      app.get('/protected/resource', keycloak.enforcer(['resource:view', 'resource:write'], {
          claims: function(request) {
            return {
              "http.uri": ["/protected/resource"],
              "user.agent": // get user agent  from request
            }
          }
        }), function (req, res) {
          // access granted

有关如何配置 Keycloak 以保护应用程序资源的详情，请参考 授权服务指南。

    function protectBySection(token, request) {
      return token.hasRole( request.params.section );
    }

    app.get( '/:section/:page', keycloak.protect( protectBySection ), sectionHandler );

高级登录配置：

默认情况下，除非您的客户端为 bearer-only，否则所有未授权的请求都会被重定向到红帽构建的 Keycloak 登录页面。但是，机密或公共客户端可以同时托管可浏览和 API 端点。要防止对未经身份验证的 API 请求重定向，而是返回 HTTP 401，您可以覆盖 redirectToLogin 功能。

例如，此覆盖检查 URL 是否包含 /api/，并禁用登录重定向：

    Keycloak.prototype.redirectToLogin = function(req) {
    const apiReqMatcher = /\/api\//i;
    return !apiReqMatcher.test(req.originalUrl || req.url);
    };

    app.use( keycloak.middleware( { logout: '/logoff' } ));

当用户触发的注销被调用查询参数 redirect_url 时，可以传递：

https://example.com/logoff?redirect_url=https%3A%2F%2Fexample.com%3A3000%2Flogged%2Fout

然后，这个参数用作 OIDC 注销端点的重定向 URL，用户将重定向到 https://example.com/logged/out。

    app.use( keycloak.middleware( { admin: '/callbacks' } );

使用 Node.js 适配器使用的完整示例可在 Node.js 的 Keycloak 快速入门中找到

为确保您的客户端兼容 FAPI，您可以在域中配置客户端策略，如 服务器管理指南 中所述，并将它们链接到 FAPI 支持的全局客户端配置文件，这些配置文件在每个域中自动可用。您可以根据您需要的客户端符合哪个 FAPI 配置集，使用 fapi-1-baseline 或 fapi-1-advanced 配置集。

如果要使用 Pushed Authorization Request (PAR)，建议您的客户端使用 fapi-1-baseline 配置文件和 fapi-1-advanced 用于 PAR 请求。具体来说，fapi-1-baseline 配置集包含 pkce-enforcer executor，这样可确保客户端使用带有安全 S256 算法的 PKCE。FAPI 高级客户端不需要此功能，除非它们使用了 PAR 请求。

如果要以 FAPI 兼容方式使用 CIBA，请确保您的客户端同时使用 fapi-1-advanced 和 fapi-ciba 客户端配置文件。需要使用 fapi-1-advanced 配置集，或者包含所请求 executors 的其他客户端配置文件，因为 fapi-ciba 配置集仅包含 CIBA 特定的 executor。当强制实施 FAPI CIBA 规范的要求时，需要更多要求，如强制机密客户端或证书边界访问令牌。

红帽构建的 Keycloak 与 Open Finance Brasil financial-grade API Security Profile 1.0 实施器 Draft 3 兼容。与 FAPI 1 高级 规格相比，这个要求严格严格，因此可能需要以更严格的方式配置客户端 策略 来强制实施某些要求。特别是：

由于机密信息正在交换，所有交互都应与 TLS (HTTPS)加密。此外，FAPI 规范中所使用的密码套件和 TLS 协议版本有一些要求。要满足这些要求，您可以考虑配置允许的密码。此配置可通过设置 https-protocols 和 https-cipher-suites 选项来实现。红帽构建的 Keycloak 默认使用 TLSv1.3，因此可能不需要更改默认设置。但是，出于某种原因，可能需要调整密码（如果需要回退到较低的 TLS 版本）。如需了解更多详细信息，请参阅配置 TLS 章节。

如果您需要手动验证红帽构建的 Keycloak 发布的访问令牌，您可以调用 Introspection Endpoint。这种方法的不足之处在于，您必须进行一个网络调用红帽 Keycloak 服务器的构建。如果您同时出现太多验证请求，这可能会很慢，并可能会过载。红帽构建的 Keycloak 发布访问令牌是 JSON Web 令牌(JWT)，使用 JSON Web 签名(JWS) 进行数字签名和编码。由于以这种方式编码了它们，因此您可以使用发布域的公钥在本地验证访问令牌。您可以在验证代码中硬编码域的公钥，或使用嵌入在 JWS 中的密钥 ID (KID) 的证书端点 来缓存公钥。根据您编码的语言，有很多第三方库，它们可帮助您进行 JWS 验证。

在使用基于重定向的流时，请确保为您的客户端使用有效的重定向 uri。重定向 uri 应尽可能具体。这特别适用于客户端（公共客户端）应用。无法这样做可能会导致：

在生产环境中，所有重定向 URI 始终使用 https。不允许重定向到 http。

还有几个特殊的重定向 URI：

bearer 令牌可以代表用户或服务帐户发布。调用端点需要以下权限( 更多详情请参阅 服务器管理指南 )：

如果您使用 bearer 令牌创建客户端，建议只使用 create-client 角色的服务帐户中的令牌（更多详情请参阅 服务器管理指南 ）。

推荐使用初始访问令牌注册新客户端的方法。初始访问令牌只能用于创建客户端，并且具有可配置的过期时间，以及创建客户端数量可配置的限制。

初始访问令牌可以通过管理控制台创建。若要创建新的初始访问令牌，首先在 admin 控制台中选择域，然后单击左侧菜单中的 Client，然后在页面中显示的选项卡中显示 Initial access token。

现在，您可以看到任何现有的初始访问令牌。如果您有访问权限，您可以删除不再需要的令牌。您只能在创建令牌时检索令牌的值。要创建新令牌，请点 Create。现在，您可以选择性地添加令牌的有效时长，还可以使用令牌创建客户端数量。点击 Save the token 值后会显示。

现在，在以后无法检索它时，您现在复制/粘贴此令牌非常重要。如果您忘记复制/粘贴，请删除令牌并创建令牌。

在调用 Client Registration Services 时，令牌值用作标准的 bearer 令牌，方法是将其添加到请求中的 Authorization 标头中。例如：

Authorization: bearer eyJhbGciOiJSUz...

当您通过客户端注册服务创建客户端时，响应将包括注册访问令牌。注册访问令牌提供了以后检索客户端配置的访问权限，但也更新或删除客户端。注册访问令牌包含在请求中，方式与 bearer 令牌或初始访问令牌相同。

默认情况下启用注册访问令牌轮转。这意味着注册访问令牌仅有效一次。使用令牌时，响应将包括新令牌。请注意，可以使用 客户端策略 禁用注册访问令牌 轮转。

如果在客户端注册服务之外创建了客户端，则它没有与之关联的注册访问令牌。您可以通过 admin 控制台创建一个。如果您丢失了特定客户端的令牌，这也很有用。若要创建新令牌，可在管理控制台中找到客户端，然后单击 Credentials。然后单击 Generate registration access token。

无论登录方法是什么，登录的帐户都需要适当的权限才能执行客户端注册操作。请记住，非 master 域中的任何帐户都只能拥有管理同一域中客户端的权限。如果需要管理不同的域，您可以在不同的域中配置多个用户，或者在 master 域中创建一个用户，并添加角色来管理不同域中的客户端。

您不能使用 Client Registration CLI 配置用户。使用 Admin Console Web 界面或 Admin Client CLI 来配置用户。如需了解更多详细信息，请参阅 服务器管理指南。

当 kcreg 成功登录时，它会接收授权令牌并将其保存到专用配置文件中，以便令牌可用于后续调用。有关配置文件的更多信息，请参阅 第 6.4.2 节 “使用其他配置”。

有关使用客户端注册 CLI 的更多信息，请参阅内置帮助。

例如，在：

$ kcreg.sh help

c:\> kcreg help

有关启动经过身份验证的会话的更多信息，请参阅 kcreg 配置凭证 --help。

默认情况下，客户端注册 CLI 会在默认位置 ./.keycloak/kcreg.config 下维护配置文件。您可以使用 --config 选项指向不同的文件或位置，以并行维护多个经过身份验证的会话。从单一线程中与单个配置文件关联的操作是最安全的方法。

您可能希望将 --no-config 选项与所有命令搭配使用，以避免将 secret 存储在配置文件中，即使它更为方便，并且需要更多令牌请求才能这样做。使用每个 kcreg 调用指定所有身份验证信息。

在 Red Hat build of Keycloak 服务器中没有配置帐户的开发人员可以使用 Client Registration CLI。只有在域管理员向开发人员发出 Initial Access Token 时，才能这样做。它是域管理员，决定如何和何时发布和分发这些令牌。域管理员可以限制 Initial Access Token 的最大年龄，以及可使用它创建的客户端总数。

开发人员有初始访问令牌后，开发人员就可以使用它来创建新客户端，而无需使用 kcreg 配置凭据进行身份验证。Initial Access Token 可以存储在配置文件中，或者指定为 kcreg create 命令的一部分。

例如，在：

$ kcreg.sh config initial-token $TOKEN
$ kcreg.sh create -s clientId=myclient

或者

$ kcreg.sh create -s clientId=myclient -t $TOKEN

c:\> kcreg config initial-token %TOKEN%
c:\> kcreg create -s clientId=myclient

或者

c:\> kcreg create -s clientId=myclient -t %TOKEN%

使用 Initial Access Token 时，服务器响应包括新发布的注册访问令牌。任何后续操作都需要通过使用该令牌进行身份验证来执行，这仅对那个客户端有效。

客户端注册 CLI 会自动使用其专用配置文件来保存并使用这个令牌与其关联的客户端使用。只要同一个配置文件用于所有客户端操作，开发人员不需要进行身份验证来读取、更新或删除以这种方式创建的客户端。

有关初始访问和注册访问令牌的更多信息，请参阅客户端注册。

运行 kcreg config initial-token --help 和 kcreg config registration-token --help 命令，以了解有关如何使用客户端注册 CLI 配置令牌的更多信息。

使用凭证进行身份验证或配置 Initial Access Token 后的第一个参数通常是创建新客户端。通常，您可能希望将准备的 JSON 文件用作模板，并设置或覆盖某些属性。

以下示例演示了如何读取 JSON 文件，覆盖它可能包含的任何客户端 id，设置任何其他属性，并在成功创建后将配置输出到标准输出。

$ kcreg.sh create -f client-template.json -s clientId=myclient -s baseUrl=/myclient -s 'redirectUris=["/myclient/*"]' -o

C:\> kcreg create -f client-template.json -s clientId=myclient -s baseUrl=/myclient -s "redirectUris=[\"/myclient/*\"]" -o

运行 kcreg create --help 以了解有关 kcreg create 命令的更多信息。

您可以使用 kcreg attrs 来列出可用的属性。请记住，许多配置属性没有检查有效或一致性。您最多指定正确的值。请记住，您的模板中不应具有任何 id 字段，不应将它们指定为 kcreg create 命令的参数。

您可以使用 kcreg get 命令检索现有客户端。

例如，在：

$ kcreg.sh get myclient

C:\> kcreg get myclient

您还可以将客户端配置作为适配器配置文件检索，您可以使用 web 应用程序打包。

例如，在：

$ kcreg.sh get myclient -e install > keycloak.json

C:\> kcreg get myclient -e install > keycloak.json

运行 kcreg get --help 命令以了解有关 kcreg get 命令的更多信息。

更新客户端配置的方法有两种。

其中一种方法是在获取当前配置后向服务器提交完整的新状态，将它保存到文件中、编辑它并将其发回到服务器。

例如，在：

$ kcreg.sh get myclient > myclient.json
$ vi myclient.json
$ kcreg.sh update myclient -f myclient.json

C:\> kcreg get myclient > myclient.json
C:\> notepad myclient.json
C:\> kcreg update myclient -f myclient.json

第二种方法获取当前客户端，设置或删除它的字段，并在一个步骤中返回。

例如，在：

$ kcreg.sh update myclient -s enabled=false -d redirectUris

C:\> kcreg update myclient -s enabled=false -d redirectUris

您还可以使用仅包含要应用的更改的文件，因此您不必将太多值指定为参数。在这种情况下，指定 --merge 告知客户端注册 CLI，而不是将 JSON 文件视为完整的新配置，应将其视为要应用到现有配置的一组属性。

例如，在：

$ kcreg.sh update myclient --merge -d redirectUris -f mychanges.json

C:\> kcreg update myclient --merge -d redirectUris -f mychanges.json

运行 kcreg update --help 命令以了解有关 kcreg update 命令的更多信息。

使用以下示例删除客户端。

$ kcreg.sh delete myclient

C:\> kcreg delete myclient

运行 kcreg delete --help 命令以了解有关 kcreg delete 命令的更多信息。

当使用 --no-config 模式执行创建、读取、更新和删除(CRUD)操作时，客户端注册 CLI 无法为您处理注册访问令牌。在这种情况下，可能会丢失对客户端最近发布的注册访问令牌的跟踪，这使得无法在该客户端上执行进一步的 CRUD 操作，而无需通过具有管理 客户端权限的账户 进行身份验证。

如果您有权限，您可以为客户端发布新的注册访问令牌，并将其输出到标准输出或保存到您选择的配置文件中。否则，您必须要求域管理员为您的客户端发布新的注册访问令牌并将其发送给您。然后，您可以通过 --token 选项将其传递给任何 CRUD 命令。您还可以使用 kcreg config registration-token 命令将新令牌保存到配置文件中，并让客户端注册 CLI 会自动为您处理它。

运行 kcreg update-token --help 命令，以了解有关 kcreg update-token 命令的更多信息。