2.2. 支持的授予类型

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

流面向 Web 应用程序，但推荐原生应用程序，包括移动应用程序，其中可以嵌入用户代理。

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

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

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

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

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

根据当前的 OAuth 2.0 安全性最佳实践，不应使用此流。此流将从将来的 OAuth 2.1 规范 中删除。

资源所有者密码凭证（称为 Direct Grant in Red Hat build of Keycloak）允许交换令牌的用户凭证。根据当前的 OAuth 2.0 安全最佳实践，不应使用这个流，首选使用替代方法，如 第 2.2.5 节 “设备授权” 或 第 2.2.1 节 “授权代码”。

使用这个流的限制包括：

此流中的安全问题包括：

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

此流不包含在 OpenID Connect 中，而是 OAuth 2.0 规格的一部分。它将从将来的 OAuth 2.1 规范 中删除。

如需了解更多详细信息，请参阅 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"

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"

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

Red Hat build of Keycloak 支持客户端使用 secret 或公钥进行身份验证。

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

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

在具有有限输入功能或缺少合适的浏览器的互联网连接设备上运行的客户端使用设备授权。

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

Client Initiated Backchannel Authentication Grant 由希望通过直接与 OpenID 提供程序通信而发起身份验证流程的客户端使用，而无需通过 OAuth 2.0 的授权代码授权等重定向。

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

收到这个 auth_req_id 后，这个客户端需要重复轮询红帽构建的 Keycloak，以获取来自红帽构建的 Keycloak 的访问令牌、刷新令牌和 ID Token，以便为 auth_req_id 返回。

如果客户端使用 ping 模式，则不需要重复轮询令牌端点，但可以等待红帽构建 Keycloak 向指定的客户端通知端点发送的通知。Client Notification Endpoint 可以在 Red Hat build of Keycloak Admin 控制台中配置。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 部分。