ID プロバイダー

ZeroClawは OpenID Connect でサインインを行い、プロバイダーが発行するアクセストークンに対して厳格です。多くのプロバイダーでは設定の変更が必要で、まだ動作しないものもあります。このページでは、プロバイダーに必要な条件、v0.9.0 プレリリースビルドでテストされたプロバイダー、まだ動作しないことが分かっているプロバイダー、現在の制限事項を一覧にしています。動作が確認されているのは Tested providers に掲載されたプロバイダーのみです。プロバイダーの設定方法については、OIDC と Dashboard sign-in を参照してください。

デーモンは、ダッシュボードでのサインインからのものでも、ネイティブクライアント（zerocode、またはzeroclaw oidc loginで取得したトークン）からのものでも、すべてのアクセストークンを同じルールで検証します。そのため、あるプロバイダーのアクセストークンが拒否されると、どこでも拒否されます。zeroclaw oidc loginとzeroclaw oidc tokenは、トークンを取得して表示するだけです。そこでサインインに成功しても、デーモンがそのトークンを受け入れることは示されません。

Providerが必要とするもの

• ディスカバリー。 <issuer>/.well-known/openid-configuration の文書が示す発行者は、末尾のスラッシュも含め、設定された issuer と完全に一致している必要があります。
• S256 による PKCE、ブラウザでのサインイン用。 ダッシュボードのサインイン、zeroclaw oidc login --browser、およびゲートウェイのブラウザ登録では、ディスカバリードキュメントの code_challenge_methods_supported に S256 が含まれている必要があります。このフィールドが省略されている発行者は拒否されます。フィールドがないことは PKCE がないことを意味し、plain は一切受け付けられません。デバイスグラントおよび client_credentials はこのフィールドを参照しません。
• デバイスグラント(zerocode および zeroclaw oidc login)。 zerocode と、--browser を付けない zeroclaw oidc login は、Device Authorization Grant(RFC 8628)でサインインします。そのため、プロバイダーがこのグラントを提供し、ディスカバリーに device_authorization_endpoint を含めている必要があります。ダッシュボードでのサインインではこのグラントは使用されません。
• ZeroClaw が検証できるアクセストークンです。validation の2つのモードのいずれかを通じて検証します:
  • jwks: RFC 9068 に準拠した JWT アクセストークンであること。ヘッダーの typ は at+jwt（または application/at+jwt）で、RS256 または ES256 で署名されている必要があります。iss、aud、exp、iat、jti を含み、クライアントは client_id で指定されている必要があります（個人のトークンの場合は azp も使用可能です）。発行者の鍵セットにある各鍵には、それぞれ独自の kid が必要です。typ が JWT の場合や typ がない JWT は拒否されます。多くのプロバイダーがデフォルトで発行する形式ですが、ID トークンと区別できないためです。
  • introspection: RFC 7662 のトークンイントロスペクションです。応答には active: true、token_type: Bearer、設定された audience、および client_id が含まれます。ディスカバリードキュメントには introspection_endpoint が記載されている必要があります。このモードでは、エントリーの client_secret が必要です。
• 別の種類のトークンであることを示すものがないこと。 どちらのモードでも、トークン（またはイントロスペクションの応答）に nonce クレームを含めてはなりません。typ または token_use クレームが存在する場合、それらはアクセストークンを指定しなければなりません。すなわち、typ は Bearer または at+jwt、token_use は正確に access でなければなりません。
• 対象者 (audience)。 アクセストークンの aud には、設定された audience が含まれている必要があります。
• 追加のスコープを必要としないロールやグループ。 ZeroClaw は openid スコープのみを要求するため、既定では claim_path の値がアクセストークン（またはイントロスペクションの応答）に含まれている必要があります。含まれていない場合は、claim_path = "sub" などを使って個々のユーザーを一人ずつマッピングしてください。
• リクエストごとのクライアント認証。 認可コードの交換(ダッシュボードへのサインイン、zeroclaw oidc login --browser、およびゲートウェイのブラウザ登録)では、client_secret をフォームボディで送信します(client_secret_post)。イントロスペクション、デバイスグラント、client_credentials では、HTTP Basic で送信します(client_secret_basic)。プロバイダーがクライアントに登録された方式のみを受け付ける場合、デバイスグラントや client_credentials 用に、別途 [oidc.<alias>] のエントリとクライアントが必要になることがあります。introspection を使うダッシュボードサインインでは、このように分けることはできません。1つのクライアントが交換とイントロスペクションの両方の呼び出しを行うため、両方の方式を受け付ける必要があります。
• 作業セッションのトークン有効期間（例：1時間から8時間）。ダッシュボードはリフレッシュトークンを使用しないため、アクセストークンが期限切れになるとセッションも終了します。

テスト済みプロバイダー

各プロバイダーで、管理者アカウントと一般メンバーアカウントのダッシュボードサインインを実施し、それぞれのクレームに対応付けられたプロファイルを確認しました。Bearerパスでは、同じプロバイダーのIDトークン、リフレッシュトークン、および同プロバイダーの別のクライアント向けに発行されたアクセストークンを、それぞれ拒否することを確認しました。テストは2026年10月および11月に、v0.9.0のプレリリースビルドに対して実施しました。Keycloakでは、ゲートウェイをHTTPおよび独自のTLSリスナーで動作させた状態で、zerocode と zeroclaw oidc login の両方を用いてテストしました。ZitadelとAutheliaはダッシュボードサインインのみでテストしました。

Keycloak

• クライアントの RFC 9068 アクセストークンヘッダーを有効にし（access.token.header.type.rfc9068 = true）、PKCE で S256 を必須にし、アクセストークンの有効期間を 1～8 時間に設定します。Keycloak のデフォルトは 5 分です。
• 設定された audience をアクセストークンに含めるオーディエンスマッパーを追加してください。
• グループメンバーシップマッパーを追加します。トークンクレーム名は groups とし、フルパスは含めず、claim_path = "groups" を対象とします。
• テスト対象のクライアントには、ハードコードされたclient_idクレームマッパーも設定されていました。マッパーがない場合は、Keycloak アクセストークンのクライアント帰属を参照してください。
• introspection を使う場合は、クライアント自身のクライアント ID を含むオーディエンスマッパーも追加してください。Keycloak 26.6.2 以降では、問い合わせ元のクライアントを指定していないトークンに対して、イントロスペクションの結果が非アクティブになります。

Zitadel

• Web アプリケーションを作成し、認証方式は Code (HTTP Basic) または Post にしてください。どちらもテスト済みです。PKCE 方式は選ばないでください。シークレットのないクライアントが作成されるため、introspection にはシークレットが必要です。ZeroClaw はどちらの方式でも PKCE チャレンジを送信します。
• プロジェクト内の各人物に役割を割り当てます。テスト対象のプロジェクトでは、ロールアサーションも有効になっていました。
• audience をプロジェクトIDに設定し、claim_path = "urn:zitadel:iam:org:project:roles" を設定してください。
• jwks は動作しません：Zitadel のアクセストークンは不透明（opaque）なトークンであるか、JWT 型の JWT です。

Authelia

• token_endpoint_auth_method: client_secret_post、access_token_signed_response_alg: RS256、PKCE S256 を指定してクライアントを登録してください。デフォルトの client_secret_basic では認可コードの交換に失敗します。
• クライアントのaudienceを設定済みのaudienceに設定し、requested_audience_mode: implicitを指定します。Authelia のデフォルトであるexplicitは、クライアントが要求した場合にのみaudienceを追加しますが、ZeroClawはaudienceを要求しません。
• claim_path = "sub" でユーザーを1人ずつマッピングします。Authelia のグループクレームには groups スコープが必要ですが、ZeroClaw はこのスコープを要求しません。
• introspection が動作しません: Authelia のイントロスペクション応答に token_type がありません。
• Authelia は発行者（issuer）を HTTPS でのみ提供するため、その証明書は、デーモンが信頼する認証局に連鎖している必要があります（制限事項を参照）。

Known not to work yet

以下はテスト済みですが、v0.9.0 で動作する設定はありません。

• Dex (v2.46.1)。そのJWTアクセストークンはヘッダーにtypを持たず、サインイン時のnonceを含んでいます。また、イントロスペクションではトークンをtoken_use: access_tokenとしてマークし、IDトークンに対しても同じように応答します。これを受け入れると、IDトークンをアクセストークンとして使用できてしまうため、引き続き拒否します。
• Authentik (2026.8.5)。そのアクセストークンはJWT型で、サインインのnonceを含み、そのイントロスペクション応答にはtoken_typeがありません。
• Logto（1.45.0、zeroclaw oidc login でテスト済み、ダッシュボードではテストしていません）。人間ユーザー向けのアクセストークンは、トークンリクエストで RFC 8707 の resource を指定しない限り不透明トークンになります。ZeroClaw はまだ resource を送信しないため、人間ユーザーはサインインできません。client_credentials を使う Logto のサービスクライアントは、デフォルトの API リソースを設定し、Logto の署名鍵を RSA にローテーションした場合にのみ動作します。Logto のデフォルト鍵は ES384 で署名しますが、ZeroClaw はこれを検証しません。

未テストです。ドキュメント、公開されているディスカバリードキュメント、ソースコードから判断すると、以下はまだ動作することが期待されていません：

• Amazon Cognito。 そのディスカバリドキュメントには S256 が記載されておらず、アクセストークンのヘッダーには typ がなく、イントロスペクションエンドポイントも存在しません。
• Ory Hydra (v26.2.0)。そのJWTアクセストークンはJWT型で、イントロスペクションは管理ポートでのみ提供され、ディスカバリーには含まれません。

その他のプロバイダー（ホスト型でもセルフホスト型でも）はテストされていません。プロバイダーに必要な要件と照らし合わせて確認してください。よくある問題は、アクセストークンがat+jwt型でないこと、イントロスペクションに対応していない不透明トークン、そしてディスカバリーでS256が公開されていないことです。

v0.9.0 の制限事項

• RFC 8707 の resource パラメーターに未対応。 名前付きのリソースに対してのみ検証可能なアクセストークンを発行するプロバイダー（Logto など）では、現時点ではサインインできません。
• 設定可能なスコープはありません。 すべてのリクエストは openid のみを要求するため、プロバイダーが他のスコープ（多くの場合 groups）でのみ提供するクレームは届きません。
• プロバイダーごとの非公開認証局は使用できません。 発行元の TLS 証明書は、デーモンが既に信頼している認証局につながっている必要があります。特定のプロバイダーに対して認証局を追加する設定はありません。
• CLI のゲートウェイ管理コマンドは、ゲートウェイ自身が TLS を提供している場合に動作しません(#12091)。
  • 対象のコマンドは、すべての形式の zeroclaw gateway get-paircode、zeroclaw sop pending、logs、approve、deny、および zeroclaw gateway restart です。
  • 常に平文のhttp://で接続するため、[gateway.tls]を有効にすると「Failed to connect to gateway」というエラーで接続に失敗します。
  • zeroclaw gateway restart は、その失敗を「実行中の gateway がない」と解釈し、同じアドレスで 2 つ目の gateway を起動しようとします。
• セッションが再検証された際のプロバイダー障害により、ダッシュボードのユーザーがサインアウトされる(#12096)。
  • ゲートウェイは、サインイン済みセッションのトークンを再度検証します:
    • at each introspection revalidation deadline (revalidation_secs);
    • 設定の再読み込み後、validation モードのいずれの場合でも;
    • ポリシーが変更されたことにより権限チェックが失敗した場合（[oidc]、[users]、[permission_profiles]、または security.trust_daemon_uid の変更）
  • プロバイダーに到達できない場合、またはエラーが返された場合、セッションは終了します。フェイルクローズ（fail closed）の動作であり、許可されるべきでないものは一切通過しません。
  • ダッシュボードはセッションが期限切れだと報告しています。ゲートウェイのログでは、実際の原因が dashboard session ended: verifying its token again failed と記録されています。
  • プロバイダーが復旧したら、ユーザーは再度サインインします。
  • 設定の再読み込みやポリシー変更がない限り、jwks セッションは再検証されません。トークンまたはセッションの有効期限が切れるまで、プロバイダーがどれだけ長くダウンしていても、検証済みの ID を保持し続けます。
  • 5分間の鍵キャッシュが影響するのは、新たに提示されるトークンだけです。たとえば新しい zerocode 接続のトークンがこれに該当します。そのトークンは、最後の鍵取得から最大5分間はキャッシュされた鍵で検証され、それ以降はプロバイダーが応答するまで拒否されます。リロードやポリシーの変更があると、キャッシュされた鍵のない状態から開始されます。
• スコープ付きアカウントのダッシュボードチャットは、接続が続いている間だけ有効です。 ページの再読み込み、チャットからの離脱、接続の切断のいずれかが発生すると会話は終了し、新しいチャットを開始すると別の会話になります。トランスクリプトは保持されますが、ダッシュボードから再度開くことはできません。詳細は ダッシュボードへのサインイン を参照してください。