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 规范 中删除。

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

使用这个流的限制包括：

与此流程相关的安全问题包括：

要使客户端被允许使用 Resource Owner Password Credentials grant，客户端必须启用 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"

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

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

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

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

在互联网连接的设备中运行的客户端使用设备授权授予功能有限，或者缺少合适的浏览器。

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