4.10. 使用基于 OAuth 2.0 令牌的身份验证

AMQ Streams 支持 OAUTHBEARER 和 PLAIN 机制进行 OAuth 2.0 身份验证。这两种机制都允许 Kafka 客户端通过 Kafka 代理建立经过身份验证的会话。客户端、授权服务器和 Kafka 代理之间的身份验证流程因每种机制而异。

建议您将客户端配置为尽可能使用 OAUTHBEARER。OAUTHBEARER 提供比 PLAIN 更高的安全级别，因为客户端凭证 永远不会 与 Kafka 代理共享。只考虑在不支持 OAUTHBEARER 的 Kafka 客户端中使用 PLAIN。

如有必要，可以在相同的 OAuth 身份验证监听器配置中同时启用 OAUTHBEARER 和 PLAIN。

使用 OAUTHBEARER 时，客户端会启动与 Kafka 代理的会话进行凭证交换，其中凭证采用回调处理程序提供的 bearer 令牌的形式。通过使用回调，您可以通过以下三种方法之一配置令牌置备：

要使用 OAUTHBEARER，您必须在 Kafka 代理的 OAuth 身份验证监听程序配置中将 sasl.enabled.mechanisms 设置为 OAUTHBEARER。有关详细配置，请参阅 第 4.10.2 节 “OAuth 2.0 Kafka 代理配置”。

listener.name.client.sasl.enabled.mechanisms=OAUTHBEARER

对于 OAuth 2.0 over PLAIN，客户端凭证不会存储在 ZooKeeper 中。相反，它们在兼容授权服务器后面被集中处理，这与使用 OAUTHBEARER 身份验证时类似。

当与 OAuth 2.0 over PLAIN 回调搭配使用时，Kafka 客户端使用以下方法之一向 Kafka 代理进行身份验证：

客户端必须启用才能使用 PLAIN 身份验证，并提供 username 和 password。如果密码前缀为 $accessToken:，后跟访问令牌的值，Kafka 代理会将密码解释为访问令牌。否则，Kafka 代理会将 username 解释为客户端 ID，password 解释为客户端 secret。

如果将 password 设置为访问令牌，username 必须设置为 Kafka 代理从访问令牌获取的相同主体名称。该进程取决于您如何使用 userNameClaim、fallbackUserNameClaim、fallbackUsernamePrefix 或 userInfoEndpointUri 配置用户名提取。它还取决于您的授权服务器；特别是，如何将客户端 ID 映射到帐户名称。

您可以在 Kafka 代理的 OAuth 验证监听程序配置中启用 PLAIN。为此，请在 sasl.enabled.mechanisms 的值中添加 PLAIN。

listener.name.client.sasl.enabled.mechanisms=OAUTHBEARER,PLAIN

有关详细配置，请参阅 第 4.10.2 节 “OAuth 2.0 Kafka 代理配置”。