Kafkaで実践する OAuth / OIDC 認証: モダンな認証とトークン管理

Kafka は SASL/OAUTHBEARER 機構で OAuth 2.0 / OIDC によるトークンベース認証を扱えます。IdP との統合により資格情報の配布を避け、ローテーションや失効を集中管理できます。

本稿は、Producer/Consumer と Broker 間のトークンフロー、最小限の設定例、トークンの寿命管理、ACL 連携のコツをまとめ、CCAAK 対策として押さえるべき比較観点も提示します。

なぜ Kafka で OAuth / OIDC か

従来の SASL/PLAIN や SCRAM では、共有シークレットの配布と保護が運用負担になりがちでした。OAuth / OIDC によるトークンベース認証では、IdP 側に認証を集約し、発行・失効・ローテーションを統一管理できます。Kafka は SASL/OAUTHBEARER を通じてこの方式を利用できます。

Kafka クライアントはアクセストークンを取得してブローカーに提示し、ブローカーはトークンを検証してから ACL に基づく認可を実施します。OIDC の標準的な JWT と JWKS による検証はプロバイダ間で安定しており、相互運用性が高いのが利点です。

• 非対話バッチやストリーミング処理では、Client Credentials フローが実務上の定番
• ブローカーは issuer / audience / 署名(JWKS) を検証し、期限(exp) や開始(not before) もチェック
• アクセストークンは短命が前提。自動リフレッシュと監視設計が鍵
• CCAAK では機構比較（PLAIN, SCRAM, OAUTHBEARER, mTLS）と運用適合性が狙われやすい

SASL/OAUTHBEARER の全体像とトークンフロー

Kafka クライアントは事前に IdP のトークンエンドポイントへ認証し、アクセストークン（多くは JWT）を取得します。接続時に SASL/OAUTHBEARER でそのトークンを提示します。ブローカーはトークンの署名とクレーム(iss, aud, exp 等)を検証し、合格すれば Kafka ACL に基づいて操作を許可します。

検証方法は主に JWKS(公開鍵セット) によるローカル検証か、トークンイントロスペクションのどちらかです。Kafka の配布やバージョンによりサポート状況や設定キー表記が異なるため、導入時は公式ドキュメントの対象バージョンを必ず確認してください。

• Producer/Consumer はアクセストークンを提示（ID トークンではない）
• Broker は JWT 署名・issuer・audience・有効期限を検証
• 認可はあくまで Kafka ACL（RBAC を使う配布版もあり）で判定

Kafka における OAuth / OIDC 認証フロー（概要）

クライアント設定: Producer/Consumer からの OIDC 連携

非対話の Kafka クライアントは、Client Credentials フローでアクセストークンを取得するのが定石です。Kafka 標準の OAuthBearerLoginCallbackHandler を使うと、設定のみでトークン取得とリフレッシュを任せられます。

リフレッシュは有効期限の手前で自動実行されます。余裕を持って更新するため、sasl.login.refresh.window.factor などの汎用 SASL リフレッシュ設定も確認してください。

• 使用するのはアクセストークン。ID トークンを提示しない
• scope や audience は IdP 側ポリシーと合致させる
• 時計ずれ対策として、全ノードで NTP を厳格化

クライアント側の最小構成例（properties）

security.protocol=SASL_SSL
sasl.mechanism=OAUTHBEARER
sasl.login.callback.handler.class=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginCallbackHandler

# OIDC のトークンエンドポイント（クライアントクレデンシャル）
sasl.oauthbearer.token.endpoint.url=https://idp.example.com/oauth2/token
sasl.oauthbearer.client.id=kafka-producer
sasl.oauthbearer.client.secret=REDACTED
sasl.oauthbearer.scope=kafka.write
# audience を使う IdP の場合
authentication.oauthbearer.audience=kafka-broker

# リフレッシュ挙動（SASL 共通）
sasl.login.refresh.window.factor=0.8
sasl.login.refresh.window.jitter=0.05
sasl.login.refresh.min.period.seconds=60

ブローカー設定とトークン検証の勘所

ブローカーは SASL/OAUTHBEARER を有効化し、JWT の検証条件（issuer, audience, JWKS エンドポイントなど）を設定します。配布やバージョンにより設定キーのスコープ（グローバル/リスナ別）や名称が異なるため、導入先の公式ドキュメントで一致を確認してください。

検証に成功すると、ブローカーはトークンのクレームからプリンシパルを組み立て（例: User:<sub>）、そのプリンシパルに対して ACL を評価します。

• SASL_SSL を推奨（少なくともネットワークは TLS で保護）
• issuer / audience の厳密一致をテストに含める
• JWKS キャッシュの TTL とローテーション時の挙動を確認

ブローカー側の例（リスナ別に OIDC/JWKS を指定）

listeners=EXTERNAL://:9093
listener.security.protocol.map=EXTERNAL:SASL_SSL
sasl.enabled.mechanisms=OAUTHBEARER
sasl.server.callback.handler.class=org.apache.kafka.common.security.oauthbearer.OAuthBearerServerCallbackHandler

# リスナ別の OIDC/JWT 検証設定（配布/版によりキー表記は要確認）
listener.name.external.sasl.oauthbearer.jwks.endpoint.url=https://idp.example.com/oauth2/keys
listener.name.external.sasl.oauthbearer.expected.issuer=https://idp.example.com/
listener.name.external.sasl.oauthbearer.expected.audience=kafka-broker

# 認可は ACL で管理。例: kafka-acls.sh で付与（運用環境に合わせて）

トークン寿命・更新・監視

アクセストークンは短寿命に設計し、自動更新で隙間を作らないのが基本です。Kafka クライアントは期限の手前で更新を試みますが、IdP 側のレート制限や一時障害に配慮してリトライ/バッファを持たせます。

運用では、トークン期限切れ・issuer/audience 不一致・署名検証失敗などの典型的な失敗パターンをメトリクス化します。ブローカー、クライアントのログとメトリクス（認証失敗数、リフレッシュ失敗数）をダッシュボードで常時可視化しましょう。

• sasl.login.refresh.window.factor を 0.7〜0.9 に設定し余裕を確保
• 全ノードの時刻同期（NTP）・TLS 期限監視は必須
• IdP の JWKS ローテーション時にキャッシュ期限と失効伝播を確認
• 障害訓練: IdP 一時停止時のクライアント再試行・キュー滞留を検証

機構比較と CCAAK の狙い所

試験では、どの機構がどの要件に適合するかを問う設問が頻出です。資格情報の配布/保護、ローテーションの容易さ、相互運用性、クライアント更新の仕組みなどを比較観点に据えると整理しやすくなります。

Confluent Cloud と自前の Confluent Platform/Apache Kafka でのサポート差にも注意しましょう。クラウドのデータプレーンは API キーによる SASL/PLAIN が主流で、OIDC は主に管理画面の SSO に使われます。プラットフォーム版では OAUTHBEARER が一般的です。

• 要件整理の軸: 機密配布の有無、ローテーション頻度、IdP/企業基盤との統合度
• クラウド利用時は“データプレーンで使える機構”を必ず確認

ACL 付与の例（プリンシパルはトークンクレーム由来）

# 例: トークンの sub が "alice" の場合にトピックへの Write を許可
kafka-acls.sh \
  --bootstrap-server broker:9093 \
  --add --allow-principal User:alice \
  --operation Write --topic orders

問題で確認

よくある質問