/realms/{realm-name}/.well-known/openid-configuration
作为完全符合 OpenID Connect 规范的提供程序实现，Keycloak 公开了一组端点，应用程序和服务可以使用这些端点来验证和授权其用户。
本节介绍了一些应用程序和服务在与 Keycloak 交互时应使用的一些关键端点。
最重要的是 well-known 配置端点。它列出了与 Keycloak 中的 OpenID Connect 实现相关的端点和其他配置选项。该端点是
/realms/{realm-name}/.well-known/openid-configuration
要获取完整 URL，请添加 Keycloak 的基本 URL 并将 {realm-name} 替换为您领域的名称。例如
http://127.0.0.1:8080/realms/master/.well-known/openid-configuration
一些 RP 库从这个端点检索所有必需的端点，但对于其他库，您可能需要单独列出端点。
/realms/{realm-name}/protocol/openid-connect/auth
授权端点执行最终用户的身份验证。此身份验证通过将用户代理重定向到此端点来完成。
有关更多详细信息，请参阅 OpenID Connect 规范中的 授权端点 部分。
/realms/{realm-name}/protocol/openid-connect/token
令牌端点用于获取令牌。令牌可以通过交换授权码或通过直接提供凭据来获取，具体取决于使用哪种流程。令牌端点还用于在访问令牌过期时获取新的访问令牌。
有关更多详细信息，请参阅 OpenID Connect 规范中的 令牌端点 部分。
/realms/{realm-name}/protocol/openid-connect/userinfo
用户信息端点返回有关已验证用户的标准声明；此端点受承载令牌保护。
有关更多详细信息，请参阅 OpenID Connect 规范中的 用户信息端点 部分。
/realms/{realm-name}/protocol/openid-connect/logout
注销端点注销已验证的用户。
用户代理可以重定向到该端点，这会导致注销活动用户会话。然后，用户代理被重定向回应用程序。
应用程序也可以直接调用该端点。要直接调用此端点，需要包含刷新令牌以及用于验证客户端的凭据。
/realms/{realm-name}/protocol/openid-connect/certs
证书端点返回由领域启用的公钥，这些公钥被编码为 JSON Web Key (JWK)。根据领域设置，可以启用一个或多个密钥用于验证令牌。有关更多信息，请参阅 服务器管理指南 和 JSON Web Key 规范。
/realms/{realm-name}/protocol/openid-connect/token/introspect
自省端点用于检索令牌的活动状态。换句话说，您可以使用它来验证访问令牌或刷新令牌。此端点只能由机密客户端调用。
有关如何调用此端点的更多详细信息，请参阅 OAuth 2.0 令牌自省规范。
您可以使用 HTTP 标头 Accept: application/jwt 而不是 Accept: application/json 来调用自省端点。如果是 application/jwt，响应可能包含带有完整 JWT 访问令牌的附加声明 jwt，这在要自省的令牌是 轻量级访问令牌 时特别有用。这要求您在客户端高级设置中启用 在自省响应中支持 JWT 声明，这将触发令牌自省。
/realms/{realm-name}/clients-registrations/openid-connect
动态客户端注册端点用于动态注册客户端。
有关更多详细信息，请参阅 客户端注册服务 指南和 OpenID Connect 动态客户端注册规范。
/realms/{realm-name}/protocol/openid-connect/revoke
令牌吊销端点用于吊销令牌。此端点支持刷新令牌和访问令牌。吊销刷新令牌时，也会吊销相应客户端的用户同意。
有关如何调用此端点的更多详细信息，请参阅 OAuth 2.0 令牌吊销规范。
/realms/{realm-name}/protocol/openid-connect/auth/device
设备授权端点用于获取设备代码和用户代码。它可以由机密客户端或公共客户端调用。
有关如何调用此端点的更多详细信息，请参阅 OAuth 2.0 设备授权授予规范。
/realms/{realm-name}/protocol/openid-connect/ext/ciba/auth
后台身份验证端点用于获取标识客户端发起的身份验证请求的 auth_req_id。它只能由机密客户端调用。
有关如何调用此端点的更多详细信息，请参阅 OpenID Connect 客户端发起的后台身份验证流程规范。
另请参阅 Keycloak 文档的其他位置，例如 本指南的客户端发起的后台身份验证授予部分 和 服务器管理指南的客户端发起的后台身份验证授予部分。
本节介绍可用于中继方 的不同授予类型。
授权码流程将用户代理重定向到 Keycloak。用户成功在 Keycloak 中进行身份验证后，会创建授权码，并将用户代理重定向回应用程序。然后，应用程序使用授权码及其凭据从 Keycloak 获取访问令牌、刷新令牌和 ID 令牌。
该流程针对的是 Web 应用程序，但也推荐用于原生应用程序（包括移动应用程序），这些应用程序可以嵌入用户代理。
有关更多详细信息，请参阅 OpenID Connect 规范中的 授权码流程。
隐式流程的工作原理类似于授权码流程，但它不返回授权码，而是返回访问令牌和 ID 令牌。这种方法减少了交换授权码以获取访问令牌的额外调用。但是，它不包括刷新令牌。这导致需要允许具有较长有效期的访问令牌；但是，这种方法不切实际，因为很难使这些令牌失效。或者，您可以在初始访问令牌过期后要求新的重定向以获取新的访问令牌。如果应用程序只想验证用户并处理注销，则隐式流程很有用。
您可以改为使用混合流程，在这种流程中，访问令牌和授权码都会返回。
需要注意的是，隐式流程和混合流程都存在潜在的安全风险，因为访问令牌可能会通过 Web 服务器日志和浏览器历史记录泄漏。您可以通过对访问令牌使用较短的有效期来缓解此问题。
有关更多详细信息，请参阅 OpenID Connect 规范中的 隐式流程。
根据当前的 OAuth 2.0 安全最佳实践，不应使用此流程。此流程已从未来的 OAuth 2.1 规范 中删除。
资源所有者密码凭据（在 Keycloak 中称为直接授予）允许用用户凭据交换令牌。根据当前的 OAuth 2.0 安全最佳实践，不应使用此流程，而是首选其他方法，例如 设备授权授予 或 授权码。
使用此流程的限制包括
用户凭据会暴露给应用程序
应用程序需要登录页面
应用程序需要了解身份验证方案
身份验证流程的更改需要更改应用程序
不支持身份代理或社交登录
不支持流程（用户自助注册、必需操作等）。
此流程的安全问题包括
涉及 Keycloak 以外的实体来处理凭据
增加易受攻击的表面积，在这些表面积中可能会发生凭据泄漏
创建用户信任另一个应用程序（而不是 Keycloak）来输入其凭据的生态系统
要允许客户端使用资源所有者密码凭据授予，客户端必须启用 启用直接访问授予 选项。
此流程未包含在 OpenID Connect 中，但它是 OAuth 2.0 规范的一部分。它已从未来的 OAuth 2.1 规范 中删除。
有关更多详细信息，请参阅 OAuth 2.0 规范中的 资源所有者密码凭据授予 章节。
以下示例展示了如何为领域 master 中用户名为 user、密码为 password 的用户获取访问令牌。此示例使用机密客户端 myclient
curl \
-d "client_id=myclient" \
-d "client_secret=40cc097b-2a57-4c17-b36a-8fdf3fc2d578" \
-d "username=user" \
-d "password=password" \
-d "grant_type=password" \
"http://127.0.0.1:8080/realms/master/protocol/openid-connect/token"当客户端（应用程序和服务）希望代表自身而不是代表用户获取访问权限时，会使用客户端凭据。例如，这些凭据对于对系统进行一般更改而不是针对特定用户进行更改的后台服务非常有用。
Keycloak 支持客户端通过密钥或公钥/私钥进行身份验证。
此流程未包含在 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，该 auth_req_id 标识客户端发起的身份验证请求。Keycloak 创建 auth_req_id。
在收到此 auth_req_id 后，此客户端需要反复轮询 Keycloak，以便在用户进行身份验证后，以 auth_req_id 为交换获取访问令牌、刷新令牌和 ID 令牌。
如果客户端使用 ping 模式，则无需反复轮询令牌端点，而是可以等待 Keycloak 发送到指定客户端通知端点的通知。可以在 Keycloak 管理控制台中配置客户端通知端点。CIBA 规范中描述了客户端通知端点合同的详细信息。
另请参阅 Keycloak 文档的其他部分，例如本指南的后端认证端点 和服务器管理指南的客户端发起后端认证授权部分。有关 FAPI CIBA 合规性的详细信息，请参阅本指南的FAPI 部分。
Keycloak 服务器可以在 OIDC 身份验证响应中向客户端应用程序发送错误，其中包含参数 error=temporarily_unavailable 和 error_description=authentication_expired。当用户经过身份验证并具有 SSO 会话，但身份验证会话在当前浏览器选项卡中过期时，Keycloak 会发送此错误，因此 Keycloak 服务器无法自动对用户进行 SSO 重新身份验证并重定向回带有成功响应的客户端。当客户端应用程序收到此类错误时，建议立即重试身份验证并将新的 OIDC 身份验证请求发送到 Keycloak 服务器，这通常应该始终由于 SSO 会话而对用户进行身份验证并重定向回。有关更多详细信息，请参见服务器管理指南。
Keycloak 使管理员更容易确保其客户端符合这些规范。
此合规性意味着 Keycloak 服务器将验证授权服务器的要求，这些要求在规范中提到。Keycloak 适配器没有对 FAPI 的任何特定支持，因此客户端（应用程序）端所需的验证可能仍然需要手动完成或通过其他第三方解决方案完成。
为了确保您的客户端符合 FAPI，您可以按照服务器管理指南 中的说明在您的领域中配置客户端策略，并将它们链接到 FAPI 支持的全局客户端配置文件，这些配置文件在每个领域中自动可用。您可以根据需要您的客户端符合哪个 FAPI 配置文件，使用 fapi-1-baseline 或 fapi-1-advanced 配置文件。您还可以使用 fapi-2-security-profile 或 fapi-2-message-signing 配置文件以符合 FAPI 2 草案规范。
如果您想使用推送授权请求 (PAR)，建议您的客户端同时使用 fapi-1-baseline 配置文件和 fapi-1-advanced 配置文件用于 PAR 请求。具体来说，fapi-1-baseline 配置文件包含 pkce-enforcer 执行器，它确保客户端使用带有安全 S256 算法的 PKCE。除非使用 PAR 请求，否则 FAPI 高级客户端不需要此要求。
如果您想以符合 FAPI 的方式使用CIBA，请确保您的客户端同时使用 fapi-1-advanced 和 fapi-ciba 客户端配置文件。需要使用 fapi-1-advanced 配置文件或包含所需执行器的其他客户端配置文件，因为 fapi-ciba 配置文件仅包含 CIBA 特定的执行器。在执行 FAPI CIBA 规范的要求时，需要更多要求，例如执行机密客户端或证书绑定访问令牌。
Keycloak 符合巴西开放金融金融级 API 安全配置文件 1.0 实施者草案 3。该配置文件在某些要求方面比FAPI 1 高级 规范更严格，因此可能需要以更严格的方式配置客户端策略以执行某些要求。特别是
如果您的客户端不使用 PAR，请确保它使用加密的 OIDC 请求对象。这可以通过使用配置了启用 Encryption Required 的 secure-request-object 执行器的客户端配置文件来实现。
确保对于 JWS，客户端使用 PS256 算法。对于 JWE，客户端应使用 RSA-OAEP 以及 A256GCM。可能需要在所有客户端设置 中设置此项，这些算法适用于这些设置。
Keycloak 符合澳大利亚消费者数据权利安全配置文件。
如果要应用澳大利亚 CDR 安全配置文件，则需要使用 fapi-1-advanced 配置文件，因为澳大利亚 CDR 安全配置文件基于 FAPI 1.0 高级安全配置文件。如果您的客户端还应用 PAR，请确保客户端应用 RFC 7637 代码交换证明密钥 (PKCE)，因为澳大利亚 CDR 安全配置文件要求在应用 PAR 时应用 PKCE。这可以通过使用包含 pkce-enforcer 执行器的客户端配置文件来实现。
由于正在交换机密信息，因此所有交互都应使用 TLS (HTTPS) 进行加密。此外，FAPI 规范中对使用的密码套件和 TLS 协议版本有一些要求。为了满足这些要求，您可以考虑配置允许的密码。此配置可以通过设置 https-protocols 和 https-cipher-suites 选项来完成。Keycloak 默认使用 TLSv1.3，因此可能不需要更改默认设置。但是，如果您需要出于某些原因回退到较低的 TLS 版本，则可能需要调整密码。有关更多详细信息，请参见配置 TLS 指南。
Keycloak 使管理员更容易确保其客户端符合这些规范。
此合规性意味着 Keycloak 服务器将验证授权服务器的要求，这些要求在规范中提到。Keycloak 适配器没有对 OAuth 2.1 的任何特定支持，因此客户端（应用程序）端所需的验证可能仍然需要手动完成或通过其他第三方解决方案完成。
为了确保您的客户端符合 OAuth 2.1，您可以按照服务器管理指南 中的说明在您的领域中配置客户端策略，并将它们链接到 OAuth 2.1 支持的全局客户端配置文件，这些配置文件在每个领域中自动可用。您可以为机密客户端使用 oauth-2-1-for-confidential-client 配置文件，或为公用客户端使用 oauth-2-1-for-public-client 配置文件。
| OAuth 2.1 规范仍然是草案，将来可能会发生变化。因此，Keycloak 内置的 OAuth 2.1 客户端配置文件也可能会发生变化。 |
| 在为公用客户端使用 OAuth 2.1 配置文件时，建议使用服务器管理指南 中描述的 DPoP 预览功能，因为 DPoP 将访问令牌和刷新令牌与客户端密钥对的公钥部分绑定在一起。此绑定可防止攻击者使用被盗令牌。 |
本节描述使用 Keycloak 保护应用程序时的一些建议。
如果您需要手动验证由 Keycloak 发行的访问令牌，则可以调用自省端点。这种方法的缺点是您必须对 Keycloak 服务器进行网络调用。如果同时有太多验证请求，这可能会很慢，并且可能会过载服务器。Keycloak 发行的访问令牌是JSON Web 令牌 (JWT)，使用JSON Web 签名 (JWS) 进行数字签名和编码。由于它们以这种方式编码，因此您可以使用发行领域的公钥在本地验证访问令牌。您可以在验证代码中硬编码领域的公钥，或者使用证书端点 和 JWS 中嵌入的密钥 ID (KID) 查找和缓存公钥。根据您使用的编码语言，存在许多第三方库，它们可以帮助您进行 JWS 验证。
在使用基于重定向的流程时，请确保为您的客户端使用有效的重定向 URI。重定向 URI 应尽可能具体。这尤其适用于客户端（公用客户端）应用程序。如果这样做失败，可能会导致
打开重定向 - 这可能允许攻击者创建看起来来自您域名的欺骗性链接
未经授权的进入 - 当用户已使用 Keycloak 进行身份验证时，攻击者可以使用重定向 URI 未正确配置的公用客户端，通过在用户不知情的情况下重定向用户来获得访问权限
在 Web 应用程序的生产环境中，始终为所有重定向 URI 使用 https。不允许重定向到 http。
还存在一些特殊的重定向 URI
http://127.0.0.1此重定向 URI 对本机应用程序很有用，它允许本机应用程序在随机端口上创建 Web 服务器，该服务器可用于获取授权代码。此重定向 URI 允许使用任何端口。请注意，根据用于本机应用程序的 OAuth 2.0，不建议使用 localhost，而应使用 IP 文字 127.0.0.1。
urn:ietf:wg:oauth:2.0:oob如果您无法在客户端启动 Web 服务器（或浏览器不可用），则可以使用特殊的 urn:ietf:wg:oauth:2.0:oob 重定向 URI。当使用此重定向 URI 时，Keycloak 会显示一个页面，其中标题和页面上的框中包含代码。应用程序可以检测浏览器标题是否已更改，或者用户可以手动将代码复制粘贴到应用程序中。使用此重定向 URI，用户可以使用其他设备获取代码以粘贴回应用程序。