2.4. 其他 OpenID Connect 库

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

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

授权端点执行最终用户的身份验证。这可以通过将用户代理重定向到此端点来实现。

如需了解更多详细信息，请参阅 OpenID Connect 规格中的 Authorization Endpoint 部分。

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

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

令牌端点用于获取令牌。令牌可以通过交换授权代码来获取，或者直接提供凭证，具体取决于所使用的流。令牌端点还用于在令牌过期时获取新的访问令牌。

如需了解更多详细信息，请参阅 OpenID Connect 规格中的 Token Endpoint 部分。

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

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

userinfo 端点返回有关经过身份验证的用户的标准声明，并由 bearer 令牌保护。

如需了解更多详细信息，请参阅 OpenID Connect 规格中的 Userinfo Endpoint 部分。

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

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

logout 端点会注销经过身份验证的用户。

用户代理可以重定向到端点，在这种情况下，活跃用户会话被注销。之后，用户代理会重新定向到应用程序。

端点也可以直接由应用调用。要直接调用此端点，需要包含刷新令牌以及验证客户端所需的凭据。

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

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

证书端点返回由域启用的公钥，并编码为 JSON Web Key(JWK)。根据域设置，可以启用一个或多个密钥来验证令牌。如需更多信息，请参阅 服务器管理指南 和 JSON Web 密钥规格。

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

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

内省端点用于检索令牌的活跃状态。换句话说，您可以使用它来验证访问或刷新令牌。它只能由机密客户端调用。

有关如何在此端点上调用的详情，请参阅 OAuth 2.0 Token Introspection specification。

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

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

动态客户端注册端点用于动态注册客户端。

如需了解更多详细信息，请参阅 客户端注册 章节 和 OpenID Connect Dynamic Client Registration 规格。

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

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

令牌撤销端点用于撤销令牌。此端点支持刷新令牌和访问令牌。

有关如何在此端点上调用的详情，请参阅 OAuth 2.0 Token Revocation 规格。

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

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

设备授权端点用于获取设备代码和用户代码。它可以通过机密或公共客户端调用。

有关如何在此端点上调用的详情，请参阅 OAuth 2.0 Device Authorization Grant 规格。

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

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

后端通道身份验证端点用于获取 auth_req_id，用于标识客户端提出的身份验证请求。它只能由机密客户端调用。

有关如何在此端点上调用的详情，请参阅 OpenID Connect Client Initiated Backchannel Authentication Flow 规格。

另请参阅 Red Hat Single Sign-On 文档中的其他部分，如 Client Initiated Backchannel Authentication Grant section of this guide 和 Server Administration Guide 中的 Client Initiated Backchannel Authentication Grant section 部分。

授权代码流将用户代理重定向到红帽单点登录。用户使用红帽单点登录验证后，会创建授权代码，用户代理会重定向到应用程序。然后，应用程序使用授权代码及其凭证从红帽单点登录获取访问令牌、刷新令牌和 ID 令牌。

流目标为 web 应用程序，但也建议用于原生应用程序，包括移动应用程序，其中可以嵌入用户代理。

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

Implicit 流重定向的工作方式与授权代码流类似，而是返回授权代码，而是返回 Access Token 和 ID Token。这可减少额外的调用来交换 Access Token 的授权代码的需求。但是，它不包括 Refresh Token。这会导致，需要一个长到期的 Access Tokens 中的一个问题，因为这很难使这些令牌无效。或 需要新的重定向以在初始访问令牌到期后获取新的访问令牌。如果应用程序只想验证用户并使用注销本身，则 Implicit 流很有用。

还有一个混合流程，其中返回 Access Token 和 Authorization Code。

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

更多详情请参阅 OpenID Connect 规格中的 Implicit 流。

资源所有者密码凭证（称为 Red Hat Single Sign-On 中的 Direct Grant）允许更改令牌的用户凭证。不建议使用这个流，除非您绝对需要。例如，这很有用的是传统应用程序和命令行界面。

使用这个流程有一些限制，包括：

要让客户端允许使用 Resource Owner Password Credentials 授权客户端启用了 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/auth/realms/master/protocol/openid-connect/token"

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/auth/realms/master/protocol/openid-connect/token"

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

Red Hat Single Sign-On 支持客户端使用 secret 或公钥/私钥进行身份验证。

这个流没有包括在 OpenID Connect 中，而是包括在 OAuth 2.0 规格中。

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

设备授权授权授权由在互联网连接的设备上运行的客户端使用，这些设备具有有限的输入功能，或缺少合适的浏览器。应用程序会要求红帽单点登录一个设备代码和用户代码。Red Hat Single Sign-On 创建设备代码和用户代码。Red Hat Single Sign-On 会返回包括设备代码和用户代码到应用程序的响应。然后，应用程序为用户提供用户代码和验证 URI。用户使用另一个浏览器访问要通过验证 URI 进行身份验证。应用程序会重复轮询红帽单点登录，直到红帽单点登录完成用户授权。如果用户身份验证完成，应用程序会获取设备代码。然后，应用程序使用设备代码及其凭证从红帽单点登录获取访问令牌、刷新令牌和 ID 令牌。

如需了解更多详细信息，请参阅 OAuth 2.0 Device Authorization Grant 规格。

客户端发起的后台身份验证 Grant 由希望通过直接与 OpenID Provider 通信来启动身份验证流的客户端使用，而无需重定向用户浏览器，如 OAuth 2.0 的授权代码授权代码授权。

客户端请求 Red Hat Single Sign-On 是一个 auth_req_id，用于标识客户端提出的身份验证请求。红帽单点登录创建 auth_req_id。

在收到此 auth_req_id 后，此客户端需要重复轮询红帽单点登录，以获取来自红帽单点登录的 Access Token、Refresh Token 和 ID 令牌，以返回 auth_req_id，直到用户被验证为止。

如果客户端使用 ping 模式，它不需要重复轮询令牌端点，但可以等待 Red Hat Single Sign-On 向指定的客户端通知端点发送的通知。可以在红帽单点登录管理控制台中配置客户端通知端点。在 CIBA 规格中介绍了客户端通知端点合同详情。

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

另请参阅 Red Hat Single Sign-On 文档的其他位置，如本指南的 Backchannel Authentication Endpoint 和 Server Administrationi ated Backchannel Authentication Grant 部分 （服务器管理指南）。有关 FAPI CIBA 合规性的详细信息，请参阅本指南的 FAPI 部分。