ログインできない

IdP は設定してあるのに、サインインが拒否される・ボタンが出ない・すぐ戻されるときに、症状から原因を探します。 IdP の設定のしかたは サインインの方法を設定する にあります。

全体像

あなたがやること	Control Plane がやること
症状を聞き、ログを読む	起動時に外した IdP と、拒否の理由をログに出す
許可リスト・名簿・IdP 側の設定を直す	許可リストと名簿の変更を、次のリクエストから効かせる

コマンドは compose の例です。ほかの形態では、その形態の runbook にある方法で Control Plane のログを読みます。

まず見るところ

症状	見るところ
全員が拒否される	許可リストが空 か、GitHub の 組織の承認
ボタンが出ない	docker compose logs cp | grep -i "login provider"
IdP の画面でエラーになる	redirect URI mismatch
Control Plane が起動しない	Entra の issuer
特定の人・特定のテナントだけ	テナントのサインイン方法
サインインしてもすぐ戻される	HTTPS

全員が拒否される

許可リスト（AF_OAUTH_ALLOWED_EMAILS・_DOMAINS・_EMAILS_FILE）がすべて空で、まだ誰もテナントに招待していないと、全員を拒否します。安全側に倒すための動きです。

• 許可リストを少なくとも 1 つ設定するか、その人をメンバーとして追加します
• _EMAILS_FILE はサインインのたびに読み直すので、足すのに再起動は要りません。招待もすぐに効きます

サインイン画面には「このアカウントはアクセスを許可されていません。管理者にメールアドレスの追加を依頼してください。」と出ます。

IdP の画面に redirect URI mismatch と出る

IdP（Google Cloud Console、Entra のアプリ登録など）に登録したリダイレクト URI が、<PUBLIC_BASE_URL>/oauth2/callback と完全に一致していません。

• PUBLIC_BASE_URL を変えたら、IdP の側もすべて直します
• IdP をいくつ有効にしても、この URI は 1 本です（リダイレクト URI を登録する）

設定したはずのボタンが出ない

設定が足りない IdP は、起動時に外されています。1 つの IdP の設定ミスで全員が締め出されないための動きです。

docker compose logs cp | grep -i "login provider"

足りない設定の名前が出ます。多いのは、既定値のない AF_OIDC_<ID>_TRUST の書き忘れです。

テナントが登録した方法のボタンが出ないときは、まだ「承認待ち」か、承認済みでも設定に不備があります。管理 → サインイン方法の登録簿 の状態で わかり、不備の中身はログの tenant login provider の行に出ます（テナント独自のサインインを承認する）。 テナントの承認済みの方法は /login には出ず、/login/<slug> にだけ出ます。これは故障ではありません。

Entra の issuer を理由に Control Plane が終わる

Entra ID の issuer が /common/・/organizations/・/consumers/ で、AF_OIDC_<ID>_ALLOWED_TIDS が空です。 このままだと Microsoft アカウントを持つ誰もがサインインを試せて、個人のアカウントは自分でメールアドレスを付け替えられます。

issuer を自社のディレクトリに固定する（https://login.microsoftonline.com/<tenant-guid>/v2.0）か、受け入れるディレクトリを並べます （Microsoft Entra ID でサインインする）。

GitHub で全員が拒否される

• 組織が OAuth App を承認していない：サードパーティの OAuth App を制限している組織は、承認するまでメンバーかどうかを見せません。docker compose logs cp | grep "returned 403" に出ます
• アドレスがドメインの外：GitHub が渡すのは、アカウントの主アドレスで確認済みのものです。個人用のアドレスだと AF_GITHUB_ALLOWED_DOMAINS の外になります。会社のアドレスを GitHub で確認して主アドレスにしてもらうか、別のボタンでサインインしてもらいます

詳しくは GitHub でサインインする にあります。

再起動のあと GitHub の人だけ、もう一度サインインを求められる

故障ではありません。組織のメンバーかどうかの結果と、それを更新するトークンはメモリにだけ持っているので、起動し直すと確かめ直す材料がなくなります。 「許可されていません」ではなく「もう一度サインインしてください」になるのはそのためです。GitHub 側のセッションが続いていれば、たいてい本人には見えません。

「このテナントには別のサインインが必要です」と出る

そのテナントの サインイン方式 で、その人が使った IdP の「受け入れる」が外れています。故障ではありません。

• セッションは 1 つの IdP にしか結び付かないので、別の方法を求めるテナントに移るにはサインインし直します。Console に「サインインし直す」が出ます
• https://<PUBLIC_DOMAIN>/login/<slug> を開けば、そのテナントが受け入れる方法だけが並びます
• 規則のほうが間違っているなら、テナントのサインイン方法の一覧で直します

「このメールアドレスは、すでにこのデプロイの別のサインイン方法で使われています」と出る

テナントが登録した方法が、すでにサインインしたことのあるアドレスを名乗りました。その方法に既存のアカウントを乗っ取らせないための動きです。

• いつも使っているサインインの方法で入ってもらいます
• 同じ GitHub アカウントなら、配備共通の GitHub とテナントの GitHub のどちらでも同じ人として通ります。これが出るのは別の IdP のボタンを押したときです
• その人が両方のアカウントを持っているなら、いつもの方法でサインインしたうえで、設定 → 個人設定 → アカウント の「サインイン方法を追加」でその方法を追加してもらいます。追加できるのは同じメールアドレスを名乗る方法だけで、その方法の組織やドメインの条件も満たす必要があります
• 相手側のアカウントを持たない人が先に進めなくなるなら、その人の方法を「受け入れる」のままにします。ボタンが邪魔なら「ボタンに出す」だけ外します

「このアカウントは、いま別のテナントの名簿に載っているためサインインできません」と出る

テナントが登録した方法で、別のテナントに有効なメンバーシップを持つ人が入ろうとしました。1 人が属するテナントは 1 つなので、故障ではありません。

1. その人を抱えているテナントが、名簿から メンバーを外す を行います。外したメンバーシップは数えません
2. 本人がもう一度サインインします

相手のテナントが応じないときは、配備管理者がそのメンバーシップを外します。どのテナントが抱えているかは af-cp identity-email-check でわかります （症状から原因を探す）。 別のテナントのサインイン方法で入っている人を招待しようとしても、identity_bound_to_other_tenant で拒否されます。

外したはずの人がまだ使える

IdP の側でアカウントを止めても、すでに持っているセッションは切れません。署名付きの Cookie は最長 AF_SESSION_TTL（既定 7 日）有効で、1 人ずつ失効させる手段はありません。

• 名簿から外す（管理 → テナント一覧 → そのテナント → メンバー → メンバーを外す）か、許可リストから消します。どちらも次のリクエストから効きます
• 全員のセッションを一度に切るなら AF_COOKIE_SECRET を入れ替えます（アクセスを取り消す・super_admin を引き継ぐ）

Cookie が保存されず、サインイン画面に戻される

AUTH=oauth は Secure 属性の Cookie を使うので、HTTPS が必須です。素の HTTP では Cookie が保存されません。

• PUBLIC_BASE_URL が https:// で始まるか
• TLS の証明書が実際に発行されているか（症状から原因を探す）

関連

• サインインの方法を設定する
• テナント独自のサインインを承認する
• 症状から原因を探す
• サインインの方法を決める（テナント管理者の手順）