OpenID Connect プロバイダーを接続

アイデンティティプロバイダーが SAML ではなく OpenID Connect を使う場合は、このガイドを参照してください。OIDC 認定の発行元であればどれでも機能します — Pocket ID、Keycloak、Auth0、Zitadel、Google Workspace などもすべて同じ手順で、違うのはプロバイダーが値を表示する場所だけです。

前提条件

• クライアントを作成できる OIDC プロバイダー — そのクライアントIDとIssuer URL（.well-known/openid-configuration ドキュメントが置かれている基底 URL）を控え、クライアントがコンフィデンシャル型の場合はクライアントシークレットも控えます（パブリックな PKCE クライアントにはシークレットはありません）
• 自分が管理する Control Center サーバー（サーバー所有者）

手順

1. 設定 → サーバー → シングルサインオンを開き、OpenID Connect に切り替えます。
2. Issuer URL、クライアントID、そしてプロバイダーが発行していれば**クライアントシークレット（任意）**を入力します。Control Center は発行元の標準ディスカバリドキュメントからエンドポイントを検出するため、プロバイダーごとの設定は不要です。
3. プロバイダー側で、そのクライアントにリダイレクト先 https://<your-server>/oidc/callback を登録します。
4. グループが groups 以外のクレームに入っている場合は、グループクレームの名前を設定します。必要ならグループをロールにマッピングします（SSO が所有者ロールを付与することは決してありません）。
5. メンバーシップポリシーを選び（全ワークスペースに自動追加、またはワークスペースごとの招待を必須にする）、サインインにOpenID Connectを使用をオンにして接続を保存を押します。
6. 接続をテストを押します — サーバーが発行元のディスカバリドキュメントを取得してエンドポイントを確認するので、緑のトーストが出ればブラウザーの往復を除くすべてが機能していることになります。クライアント登録も確認するには、下のチェッカーを使います。
7. ログインを試します: Web の接続画面にはOpenID Connectでサインインと表示されるので、そこからサインインするか、https://<your-server>/oidc/login を直接開きます。

クレーム（email、name、groups）は、あなたのサーバーが TLS 経由で発行元のトークンエンドポイントから読み取ります — ブラウザーがこれらを渡すことはないため、ローカルでの JWT 署名検証は関与しません。クライアントには openid profile email スコープの要求を許可しておく必要があります。これはまさに Control Center が要求する内容です。

クレームを認証しているのはこの TLS チャネルだけなので、Issuer URL は https でなければなりません — 平文の発行元を使うと、経路上の攻撃者がアイデンティティを好き放題に偽造できてしまいます。http が許可されるのは、ローカル開発向けにループバックの発行元（localhost、127.0.0.1、::1）だけでです。

パブリッククライアントかコンフィデンシャルクライアントか

既定で推奨される形は、PKCE（RFC 7636）を使った認可コードフローのパブリッククライアントです。サーバーが保持するワンタイムのコードベリファイアがシークレットの代わりになり、トークン交換はそれを開始した認可リクエストに結び付けられます。漏えいするシークレットはなく、認可コードが盗まれてもベリファイアがなければ役に立ちません。プロバイダーによっては、作成時にこれを「SPA」や「native」というクライアントタイプと呼びます。

プロバイダーが代わりにコンフィデンシャルクライアントを発行した場合は、プロバイダー側でクライアントをパブリックとして扱うか（どちらでも PKCE は有効なままです）、クライアントシークレットを接続の**クライアントシークレット（任意）**フィールドに貼り付けます。シークレットはサーバーの 0600 のシークレットファイルに保存され（データベースには保存されません）、client_secret_post としてトークンエンドポイントに送信され、RPC で返されることはありません。保存時にフィールドを空のままにすると、保存済みのシークレットが維持されます。トークン交換でログインが失敗した場合、サーバーログにプロバイダー自身のエラーが記録されます（invalid_client はほとんどの場合、シークレットの欠落か誤りを意味します）。

到達可能性

ログイン自体はブラウザー経由で行われます。発行元はユーザーのブラウザーを /oidc/callback にリダイレクトするだけで、あなたのサーバーがトークンエンドポイントへ外向きの HTTPS 呼び出しを行います — 発行元からの受信接続は不要なので、NAT の内側にあるサーバーでも、ユーザーのブラウザーから到達できれば（LAN、VPN、Tailscale、トンネルなど）機能します。SCIM プロビジョニングは例外です: IdP があなたのサーバーを直接呼び出すため、トンネルまたは公開 URL が必要になります — SCIM でユーザーをプロビジョニング を参照してください。

このページから設定を確認する

下のチェッカーはブラウザー内で実行されます。発行元のディスカバリドキュメントを直接取得するため、このサイトがそれを目にすることはありません。そしてサーバーのルールを適用します。ドキュメントと一致する https の発行元、発行元自身のオリジン上のエンドポイント、PKCE S256、およびクライアントタイプに必要なトークン認証方式です。クライアントIDとサーバーアドレスを指定すると、クライアントとそのリダイレクト URI が登録されているかを示すテストサインインを開けます。クライアントシークレットを求めることはありません。

Runs in your browserYour browser fetches the discovery document straight from your issuer. Add a server address and it also asks that server which sign-in methods it offers. This site never receives what you type.

Issuer URL

Client ID (optional)

Needed for the test sign-in.

Groups claim (optional)

Client type

Public, PKCE only Confidential, has a client secret

Never paste the secret here. The check only needs to know whether one exists.

Server address (optional)

The address your users open. Adds a reachability check and a test sign-in.

Paste the discovery document instead

Discovery document JSON

For providers that block other sites from reading it.

Check issuer