Azure CIAM（Microsoft Entra External ID）の OIDC で、MSA や Google 認証だけ「redirect_uri 不一致」で落ちてしまう――実はこれは CIAM 特有の仕様と設定手順を理解していれば、再現性高く解消できる典型パターンです。本記事では原因の整理から具体的な設定手順、デバッグの勘所、通常テナントとの違いまでを一気に整理します。
この記事の結論（先にまとめ）
先に結論だけ知りたい方向けに、ポイントを整理します。
- Azure CIAM（Microsoft Entra External ID）の OIDC で MSA/Google 認証が
redirect_uri 不一致になる原因は、外部 ID プロバイダー側（MSA / Google）の「開発者ポータル」に CIAM 用のリダイレクト URI が登録されていない／1 文字でも違うからです。 - CIAM テナントでは、MSA や Google 向けに
https://<TENANTGUID>.ciamlogin.com/...のような専用リダイレクト URI が自動生成されます。
この URI は Entra 管理センターの「External ID > ID プロバイダー」画面に表示される値をそのままコピペする必要があります。 - MSA（個人 Microsoft アカウント）は、CIAM では live.com へのフェデレーションが強制されており、メール OTP など別方式に置き換えることはできません。
- 同じアプリが通常（Workforce）テナントだと動くのは、CIAM 固有の
ciamlogin.comのリダイレクト URI 要件に縛られていないためです。 - IdP 側で CIAM 提示のリダイレクト URI を「完全一致」で登録し、client_id / client_secret を Entra の External ID 設定に貼り付ければ解決します。
Azure CIAM（Microsoft Entra External ID）と OIDC の前提整理
CIAM テナントと通常（Workforce）テナントの違い
まずは前提になるテナント種別の違いを軽く整理しておきます。
| 項目 | CIAM テナント（External） | 通常テナント（Workforce） |
|---|---|---|
| 主な用途 | 顧客向けアプリ（BtoC）・外部ユーザー | 社内ユーザー・BtoB 連携 |
| サインインドメイン | *.ciamlogin.com | *.login.microsoftonline.com |
| 代表的な機能 | セルフサインアップ、ブランドドメイン、Email OTP など | 条件付きアクセス、内向け SSO など |
| 外部 ID プロバイダー | MSA / Google / Apple / Facebook 等を顧客用に統合 | 企業間フェデレーション（外部 IdP との SSO が中心） |
| 本記事の問題 | MSA / Google 認証時に redirect_uri 不一致 | 同じアプリ構成でも問題が出ないことが多い |
今回の「MSA / Google 認証だけ redirect_uri 不一致」という事象は、CIAM テナント特有のリダイレクト URI 仕様に起因するものです。
CIAM における外部 ID プロバイダーの位置づけ
Entra External ID（CIAM）では、ユーザーがサインインする入り口は主に 3 つに分かれます。
- ローカルアカウント（メール＋パスワード or OTP）
- MSA（Outlook.com / Hotmail.com など）
- Google / Apple / Facebook / その他 OIDC / SAML IdP
外部 IdP（MSA、Google など）を使う場合、CIAM 自体も OIDC クライアントとして振る舞い、MSA や Google の「開発者ポータル」で以下を設定します。
- CIAM が使うリダイレクト URI
- client_id / client_secret
- スコープや認可済みドメインなど
ここでのリダイレクト URI が 1 文字でもズレると IdP 側で invalid_request: redirect_uri mismatch となり、CIAM 側から見ると「外部プロバイダー認証で失敗した」ように見えます。
redirect_uri 不一致エラーが起こるメカニズム
エラー内容のイメージ
MSA 側のログやブラウザーのアドレスバーに、例えば次のようなエラーが見えることがあります。
error=invalid_request
error_description=The provided value for redirect_uri does not match the registered redirect_uri.ここで重要なのは、redirect_uri は OIDC / OAuth2 の仕様上、
- 事前に IdP のアプリ登録で保存している値と「完全一致」している必要がある
- URL エンコードされた状態でも、復元すると完全一致である必要がある
という点です。
CIAM 固有のリダイレクト URI 例
CIAM テナントでは、MSA や Google を外部 ID プロバイダーとして追加したときに、Entra 管理センター上に次のようなリダイレクト URI が表示されます（例）：
https://<TENANTGUID>.ciamlogin.com/common/federation/oauth2msa
https://<TENANTGUID>.ciamlogin.com/common/federation/oauth2google※実際のパスはテナントや設定により異なる場合があります。必ずポータルに表示された文字列をコピペしてください。
これを外部 IdP 側（MSA のアプリ登録、Google Cloud Console など）に、1 文字も違えず登録する必要があります。
次のような「ほんの少しの差分」でも、すべて NG です。
| 登録してしまいがちな URI | 何がダメか |
|---|---|
https://<TENANTGUID>.ciamlogin.com/common/federation/oauth2msa/ | 末尾に / が増えている |
https://<TENANTNAME>.ciamlogin.com/common/federation/oauth2msa | TENANTGUID を名前に置き換えてしまっている |
HTTPS://<TENANTGUID>.CIAMLOGIN.COM/common/federation/oauth2msa | ホスト部分の大文字小文字差分（実装によっては NG） |
https://<TENANTGUID>.ciamlogin.com/common/federation/oauth2msa?foo=bar | 余計なクエリパラメーターが付いている |
CIAM の場合、redirect_uri は CIAM 側で決め打ちされており、アプリ開発者が自由に変えられません。 そのため、外部 IdP 側の設定を「CIAM に合わせる」ことが必須です。
MSA（個人 Microsoft アカウント）連携の正しい設定手順
ここからは、実際に MSA（個人 Microsoft アカウント）と連携する際の手順を整理します。
1. Entra 管理センター（CIAM 側）で MSA プロバイダーを確認
- Entra 管理センターにサインインします。
- External ID > ID プロバイダー を開きます。
- 「Microsoft アカウント」（または類似の名称）を追加します。
- 構成ウィザード内に表示される リダイレクト URI をすべて控えます。
例：https://<TENANTGUID>.ciamlogin.com/common/federation/oauth2msa
ここで控えた URI が、後続の MSA アプリ側設定の「正解」です。
2. MSA 側（個人 Microsoft アカウント）のアプリ登録
MSA のアプリ登録は、通常の Azure AD アプリとは別のポータルで行うケースがありますが、ここでは一般的なパターンとして以下を想定します。
- MSA 用のアプリ登録ページにサインインします（個人アカウントでログイン）。
- 新しいアプリケーションを作成し、プラットフォームを 「Web」 として構成します。
- SPA やネイティブアプリとして登録すると、
form_postなどのレスポンスモードで不整合が起きやすいので、まずは Web アプリとして登録するのが無難です。
- SPA やネイティブアプリとして登録すると、
- リダイレクト URI の欄に、Entra 管理センターで控えた URI を完全一致で入力します。
- コピペ後、余計な空白や末尾のスラッシュが付いていないか目視で確認しましょう。
- スコープは、最低限以下を登録します。
openidprofileemail- 必要に応じて
offline_access
- アプリ登録が完了したら、client_id と client_secret を控えます。
3. Entra External ID（CIAM）の MSA プロバイダー設定を完了
- 再度、Entra 管理センターの External ID > ID プロバイダー > Microsoft アカウント を開きます。
- 先ほど控えた client_id / client_secret を入力します。
- 構成を保存し、テスト用アプリから MSA サインインを試行します。
ここまで正しく設定できていれば、redirect_uri 不一致のエラーは解消され、MSA 経由で CIAM へのサインインが正常に完了するはずです。
Google 認証連携の正しい設定手順
1. Entra 管理センター（CIAM 側）で Google プロバイダーを確認
- Entra 管理センターで External ID > ID プロバイダー を開きます。
- Google を追加または編集します。
- 表示される Google 用のリダイレクト URI をすべて控えます。
https://<TENANTGUID>.ciamlogin.com/common/federation/oauth2google
2. Google Cloud Console 側の設定
- Google Cloud Console にアクセスし、対象のプロジェクトを開きます。
- 「API とサービス」 > 「認証情報」 を開きます。
- 「OAuth クライアント ID」 を作成し、アプリケーションの種類は 「ウェブ アプリケーション」 を選択します。
- Authorized redirect URIs に、Entra 管理センターで控えたリダイレクト URI を完全一致で追加します。
- 保存後に表示される クライアント ID / クライアント シークレット を控えます。
- Google の OAuth 同意画面設定にて、
- 公開ステータス（テスト / 本番）
- 必要に応じたテストユーザーの登録
- スコープ（
email、profileなど）
3. Entra External ID 側に Google のクライアント情報を登録
- Entra 管理センターに戻り、External ID > ID プロバイダー > Google の設定を開きます。
- Google Cloud Console で取得した client_id / client_secret を入力します。
- 保存し、CIAM に連携したアプリから Google サインインを試します。
Google 側で Authorized redirect URIs が正しく登録されていれば、ここでも redirect_uri mismatch のエラーは発生しなくなります。
redirect_uri 不一致エラーのデバッグチェックリスト
うまくいかない場合に見るべきポイントを、チェックリスト形式で整理します。
| 確認項目 | 具体的な確認方法 | OK な状態 |
|---|---|---|
| redirect_uri の完全一致 | ブラウザーのアドレスバーやネットワークトレースで、redirect_uri の値を URL デコードして確認する。 | IdP の開発者ポータルに登録された値とバイト単位で一致している。 |
| 末尾スラッシュ | CIAM が表示している URI に / が付いているかどうかを確認し、IdP 側も同じにする。 | 有り無しが完全に一致している。 |
| 大文字小文字 | CIAMLOGIN.COM のように大文字化していないか確認。 | ポータル表示の通りの表記になっている。 |
| 不要なクエリ | ?foo=bar のような追加パラメータが付いていないか確認。 | ポータル表示と同じパス・クエリのみが付いている。 |
| テナント GUID の誤り | 似た GUID をコピペしていないか、別テナントの GUID になっていないか確認。 | CIAM 対象テナントの GUID と一致している。 |
| アプリ種別 | IdP 側のアプリ種別が「Web」になっているか確認（SPA / ネイティブではない）。 | プラットフォームが Web / Web アプリケーションに設定されている。 |
| Google 同意画面 | Google の OAuth 同意画面が「テスト」状態の場合、テストユーザーに対象ユーザーが含まれているか確認。 | 本番公開済み、またはテストユーザーに含まれるユーザーで認証している。 |
| ブラウザーキャッシュ | シークレットウィンドウや別ブラウザーで再試行。 | 古いセッションに依存せず再現テストできる。 |
特に、URL デコードした redirect_uri を、そのまま IdP 側の設定画面に貼り付けてみると、ほんのわずかな違いに気付けることが多いです。
なぜ通常（Workforce）テナントでは問題が出なかったのか
同じアプリ構成を通常テナントで試したときに、なぜか問題なく動く、というケースがあります。これは、次のような理由が考えられます。
- 通常テナントでは、
login.microsoftonline.com側の URIを元にアプリを登録しており、既に IdP 側に正しい redirect_uri が登録済みだった。 - たまたま以前の検証で登録していた URI と、今回の URI が偶然一致していた。
- CIAM 固有の
ciamlogin.comドメインを意識せず、通常テナントと同じ URI だと誤認していた。
つまり、通常テナントで動いたからといって、その設定が CIAM にもそのまま通用するとは限らないということです。
CIAM では「外部 IdP 側にも CIAM 専用 URI を登録する」という 1 工程が増えると理解しておくと、認知のギャップが埋めやすくなります。
仕様面で誤解しがちなポイント
MSA の経路は CIAM で事実上「強制」
MSA（個人 Microsoft アカウント）は、CIAM では live.com へのフェデレーション経路が事実上固定されています。
- MSA ドメイン（
@outlook.com、@hotmail.comなど）のメールアドレスに対して、Email OTP のみでサインインさせる、といった構成はできません。 - MSA を使うなら、MSA フェデレーションを正しく構成するしか選択肢がないと考えた方がスムーズです。
サインアップ可否と IdP フェデレーションは別の話
「自己登録（セルフサインアップ）を無効にしていると、MSA や Google 連携が使えないのでは？」という質問もよくありますが、これは NO です。
- サインアップ可否の設定は、CIAM 内部でアカウントを新規作成するかどうかに関するものです。
- MSA / Google 認証は、外部 IdP としてのフェデレーションであり、サインアップを禁止していても認証自体は可能です。
したがって、自己登録をオフにしていても、redirect_uri が正しく設定されていればサインインは成功します。
運用設計とベストプラクティス
本番・検証環境ごとのリダイレクト URI 管理
CIAM テナントを複数（本番用と検証用など）持つ場合、それぞれで <TENANTGUID> が異なります。そのため、
- 検証用 CIAM の
*.ciamlogin.com - 本番用 CIAM の
*.ciamlogin.com
の 2 パターンのリダイレクト URI を、MSA / Google 側それぞれに登録しておく必要があります。
| 環境 | テナント | 例：MSA 用リダイレクト URI |
|---|---|---|
| 検証 | CIAM-DEV | https://11111111-1111-1111-1111-111111111111.ciamlogin.com/common/federation/oauth2msa |
| 本番 | CIAM-PROD | https://22222222-2222-2222-2222-222222222222.ciamlogin.com/common/federation/oauth2msa |
どの URI がどの環境に対応しているかをドキュメント化し、本番切り替え時に「検証用 URI のまま」になっていないかを必ずレビューする運用をおすすめします。
アプリ開発側への共有内容
アプリ開発チームに対しては、次の 3 点を最初に共有しておくとトラブルが減ります。
- CIAM テナントでは redirect_uri を自由に変えられない（CIAM が決める）。
- 外部 IdP 側の設定が 1 文字でもズレると redirect_uri mismatch で必ず失敗する。
- エラーが出たときは、ブラウザーのアドレスバーの redirect_uri をそのままスクリーンショット or コピペしてもらうと解析が早い。
これだけで、「アプリコードのバグでは？」といった無用な議論を減らすことができます。
よくある質問と落とし穴
Q. MSA ユーザーをメールのワンタイムパスコード（OTP）でサインインさせたい
A. 現状、CIAM では実質不可です。
- MSA ドメインのメールアドレスは、CIAM 側で MSA（live.com）へのリダイレクトが強制されます。
- メール OTP のみで完結させるルートには変更できません。
- MSA ユーザーを扱う場合は、MSA フェデレーションを正しく構成することが前提になります。
Q. サインアップ（自己登録）を無効にしていると、MSA/Google 連携は使えない？
A. 影響しません。
- サインアップの可否は 新規アカウント作成の制御であり、既存ユーザーのサインインや、外部 IdP からのフェデレーションそのものとは別です。
- MSA / Google 側のアプリ登録とリダイレクト URI が正しく一致していれば、サインアップを無効にしていてもサインインは成功します。
Q. CIAM の運用が重く感じる場合、通常テナントや他 ID 基盤に戻すべき？
A. ユースケース次第ですが、「顧客向け」であれば CIAM を推奨します。
- 顧客向けのセルフサインアップ、ブランドドメイン、Email OTP、スケーラビリティなど、BtoC に必要な機能は CIAM に集約されています。
- 一方で、社内ユーザー中心のシナリオや、既に別の顧客 ID 基盤が存在するケースでは、通常テナントや他サービスと役割分担するのも選択肢です。
今回のような redirect_uri 不一致は、CIAM の「難しさ」ではなく、仕様上必須の手順漏れであることが多いので、仕組みを一度きちんと整理すれば、運用負荷は大きく下げられます。
実務でのトラブルシュート例
最後に、実務でありがちなパターンを 2 つほど挙げておきます。
パターン1：テナントを作り直したら突然失敗するようになった
- 検証中に CIAM テナントをいったん削除し、新しいテナントを作成した。
- MSA / Google のアプリ登録はそのまま流用した。
- 新 CIAM の
<TENANTGUID>は当然変わっているが、外部 IdP 側の redirect_uri を更新し忘れた。
この場合、ブラウザーに表示される redirect_uri と、IdP 側に登録されている URI を比較すると、GUID 部分が異なっているはずです。
解決策はシンプルで、「新 CIAM テナントのリダイレクト URI で IdP の設定を更新する」だけです。
パターン2：本番切り替え後だけ Google 認証が失敗する
- 検証環境では Google 認証が正常に動いていた。
- 本番環境に切り替えたところ、Google 認証のみ
redirect_uri mismatchで落ちる。 - 原因を調べると、Google Cloud Console の Authorized redirect URIs に「検証 CIAM 用の URI しか登録されていなかった」。
このケースも、本番 CIAM 用のリダイレクト URI を追加登録するだけで解決します。
Google は複数のリダイレクト URI を登録可能なので、本番と検証を併存させる運用も十分可能です。
まとめ
Azure CIAM（Microsoft Entra External ID）の OIDC で、MSA や Google 認証だけが redirect_uri 不一致 で失敗する問題は、ほぼ例外なく、
- 外部 IdP 側（MSA / Google）の開発者ポータルに、CIAM 専用のリダイレクト URI が完全一致で登録されていない
ことが原因です。
対応のポイントは次の 3 つです。
- Entra 管理センターの External ID > ID プロバイダー に表示されるリダイレクト URI を、そのままコピペして IdP 側に登録する。
- MSA / Google 側では、アプリ種別を Web アプリ とし、client_id / client_secret を CIAM 側に正しく登録する。
- エラー時は、URL デコードした redirect_uri と、IdP 側の登録値をバイト単位で比較して差分を探す。
これらを押さえておけば、「CIAM だと MSA/Google 認証がなぜか動かない」という初期のつまづきはほぼ解消できます。
今後 CIAM を本番導入していく際には、本記事の内容をチェックリスト化しておくと、チーム内でのトラブルシュートもスムーズになるはずです。
コメント