2.2. OAuth 2.0 認証および承認

本リリースには、OAuth 2.0 トークンベースの認証および承認に対して改良された以下の機能が含まれています。

JWT アクセストークンのチェック

JWT アクセストークンに、2 つの追加チェックを設定できるようになりました。これらのチェックはいずれも OAuth 2.0 認証リスナー設定で設定されます。

カスタムクレームチェック

カスタムクレームチェックでは、Kafka ブローカーによる JWT アクセストークンの検証にカスタムルールが適用されます。これらは JsonPath フィルタークエリーを使用して定義されます。

アクセストークンに必要なデータが含まれていないと拒否されます。イントロスペクションエンドポイントトークン検証を使用する場合は、カスタムチェックがイントロスペクションエンドポイントの応答 JSON に適用されます。

カスタムクレームチェックを設定するには、oauth.custom.claim.check オプションを server.properties ファイルに追加し、JsonPath フィルタークエリーを定義します。カスタムクレームチェックはデフォルトで無効になっています。

Kafka ブローカーの OAuth 2.0 サポートの設定」を参照してください。

オーディエンスチェック

承認サーバーは、JWT アクセストークンに aud (オーディエンス) クレームを提供することがあります。

オーディエンスチェックが有効な場合、Kafka ブローカーは aud クレームにブローカーの clientId が含まれていないトークンを拒否します。

オーディエンスチェックを有効にするには、oauth.check.audience オプションを true に設定します。オーディエンスチェックはデフォルトで無効になっています。

Kafka ブローカーの OAuth 2.0 サポートの設定」を参照してください。

SASL PLAIN 認証での OAuth 2.0 のサポート

Kafka クライアントと Kafka ブローカー間の OAuth 2.0 認証に PLAIN メカニズムを設定できるようになりました。これまでは、認証されるメカニズムは OAUTHBEARER のみでした。

PLAIN は、すべての Kafka クライアントツール(kafkacat などの開発者ツールを含む)によってサポートされる簡易認証メカニズムです。AMQ Streams には、PLAIN を OAuth 2.0 認証と使用できるようにするサーバー側のコールバックが含まれています。これらの機能は OAuth 2.0 over PLAIN と呼ばれます。

注記

Red Hat は、可能な限りクライアントに OAUTHBEARER 認証を使用することを推奨します。OAUTHBEARER では、クライアントクレデンシャルは Kafka ブローカーと共有されることがないため、PLAIN よりも高レベルのセキュリティーが提供されます。OAUTHBEARER をサポートしない Kafka クライアントの場合のみ、PLAIN の使用を検討してください。

提供される OAuth 2.0 over PLAIN コールバックと併用すると、Kafka クライアントは以下のいずれかの方法を使用して Kafka ブローカーで認証することができます。

  • クライアント ID およびシークレット (OAuth 2.0 クライアントクレデンシャルメカニズムを使用)
  • 設定時に手動で取得された有効期限の長いアクセストークン

PLAIN を使用するには、OAuth 認証リスナー設定で server.properties ファイルで有効にする必要があります。

OAuth 2.0 認証メカニズム 」および「 Kafka ブローカーの OAuth 2.0 サポートの設定」を参照してください。