Entra External ID（CIAM）のExternalテナントで「ユーザーフローが作れない／一覧に出ない」「サインインしてもjwt.msでトークンが見られない」という症状は、設定ミスというより“管理ポータルの使い分け”と“テスト時の応答タイプ”が原因になりやすいトラブルです。本記事では、最短で復旧するためのチェックポイントと手順を、画面操作ベースで整理します。
起きている症状を整理する
External tenant（顧客向け External ID / CIAM）でユーザーフローを触り始めた直後に、次のような現象が同時に起きることがあります。
- ユーザーフローの作成が失敗する、または作成できても「User flows」一覧にすぐ反映されない（しばらくしてから見える）
- どのユーザーフローを実行してもトークンが取得できない／jwt.ms に貼って確認できない（jwt.ms に遷移しても何も出ない）
結論から言うと、原因は大きく2つに収束するケースが多いです。
| 原因 | 起こりやすい症状 | 一番効く対処 |
|---|---|---|
| portal.azure.com と entra.microsoft.com を行き来している | 作成失敗／一覧が不安定／反映が遅い／画面が古い状態で表示される | Entra 管理センター（entra.microsoft.com）に統一して作成・確認・テスト |
| テストで id_token を返す設定になっていない（＋アプリ側の許可不足） | jwt.ms で確認できる ID トークンが手に入らない | ユーザーフローテストのResponse type を id_tokenにし、アプリ登録でID tokens を有効化 |
まずは5分で直す：最短復旧チェックリスト
「何が悪いかを細かく切り分ける前に、とにかく正常系を作りたい」場合は、次のチェックを上から順に実施してください。External tenant の CIAM は管理面で挙動が“揺れる”ことがあるため、最短ルートで正常系を作るのがコツです。
| チェック項目 | 場所 | OKの状態 | NGならどうする |
|---|---|---|---|
| 管理ポータルを統一している | ブラウザ | 作業は entra.microsoft.com だけ | Azureポータルを閉じ、Entra管理センターで作り直し／確認 |
| 対象テナントが External tenant になっている | Entra管理センター右上のディレクトリ切替 | 顧客向けExternalテナントが選択されている | ディレクトリを切り替え、別タブで開き直す |
| ユーザーフローのテストが id_token を返す | User flows の「Run user flow（実行／テスト）」 | Response type に id_token が選べる／選んで実行 | Response type を id_token に変更 |
| アプリ登録の Redirect URI が正しい | App registrations → Authentication | ユーザーフローテストのリダイレクト先と一致 | Redirect URI を追加／修正 |
| アプリ登録で ID tokens が許可されている | Authentication → Implicit grant and hybrid flows | ID tokens が ON | ID tokens を ON（※必要な範囲で） |
原因1：AzureポータルとEntra管理センターの“行き来”で表示・反映が不安定になる
External ID for customers（CIAM）の External tenant は、管理機能が Entra 側に強く寄っています。にもかかわらず、portal.azure.com（Azureポータル）側にも似たメニューが見えてしまうため、つい両方を触ってしまいがちです。
しかし External tenant に関しては、Azureポータル側が管理対象として完全対応していなかったり、画面反映が遅かったり、表示キャッシュの影響を受けたりする場面があり、次のような“わかりづらい失敗”につながります。
- 作成直後なのに一覧に出ない（別ポータルでは見える／見えないが分かれる）
- 作成は成功したはずなのに、次の画面で「存在しない」扱いになる
- 「作成ボタンが押せるのに失敗する」「設定が保存できない」など、UI不具合のように見える
対処：作成・確認・テストを entra.microsoft.com に統一する
根本解決はシンプルで、External tenant の User flows に関する操作をEntra 管理センター（entra.microsoft.com）に寄せることです。
- entra.microsoft.com にサインイン
- 右上のディレクトリ切り替えで対象のExternal tenantを選択
- User flows の作成・編集・実行テストを、以降すべて Entra 管理センターで行う（Azureポータルでは操作しない）
画面反映が怪しい時の一時的な切り分けとして、InPrivate（シークレット）で試す、ハードリロード（Ctrl+F5）、別ブラウザで試すは有効です。ただし根本対応は「ポータル統一」です。
原因2：ユーザーフローのテストで id_token を返していない（＋アプリ登録の許可不足）
jwt.ms は「受け取ったトークン（JWT）をデコードして見せる」ための確認用サイトです。つまり、トークンが手元に届いていない場合は、当然 jwt.ms では何も確認できません。
IDトークンとアクセストークンの違いを押さえる
| トークン | 用途 | jwt.ms で見たい場面 | 主に関係する設定 |
|---|---|---|---|
| ID token（id_token） | 「誰がサインインしたか」をアプリに伝える（OpenID Connect） | ユーザー識別（sub、name、email 等）や issuer、ポリシー（フロー）の確認 | Response type、openid スコープ、ID tokens 許可 |
| Access token（access_token） | APIを呼ぶための権限（OAuth 2.0） | aud、scp/roles、付与された権限の確認 | API の公開、Scopes、同意、クライアント設定 |
Entra 管理センターからユーザーフローを「その場でテスト」する場合、Response type（応答タイプ）で id_token を選ばない限り、jwt.ms に貼って確認したい ID トークンが返ってきません。さらにアプリ登録側でImplicit grant / ハイブリッド フローの「ID tokens」を許可していないと、テストが途中で止まったり、期待したトークンが返らなかったりします。
注意：本番アプリは「認可コード + PKCE」が基本
ここで出てくる「Implicit grant / ハイブリッド フロー（ID tokens）」は、主にポータル上の簡易テストや特定のクライアントで必要になる設定です。実運用のアプリが認可コードフロー（Authorization Code Flow）+ PKCE を使う場合、必ずしも Implicit を ON にし続ける必要はありません。
ただし今回の「jwt.ms で見たい」という目的に対しては、まずテストが成立する状態を作るのが優先です。動作確認が終わったら、社内のセキュリティ基準に合わせて設定を見直してください。
手順：Entra管理センターでUser flowsを作成し、確実に一覧に出す
以下は「作成できない／一覧に出ない」を避けるための基本手順です。External tenant では、作業途中で別のポータルに移動しないことが重要です。
- entra.microsoft.com にアクセスし、対象の External tenant に切り替える
- External ID（または Customers）配下の User flows を開く
- 新規ユーザーフローを作成し、保存する
- 保存後、同じ画面を別タブで開き直し、一覧に反映されているか確認する
「一覧に出ない」時の切り分け表
| 現象 | まず疑うポイント | 確認方法 | 対処 |
|---|---|---|---|
| 作成後すぐに一覧に出ない | 表示の遅延／キャッシュ | 同一テナントで InPrivate を開く | Entra管理センターで再読み込みし、時間をおいて再確認 |
| 別タブでは見えるが、このタブでは見えない | 画面キャッシュ | ハードリロード（Ctrl+F5） | タブを閉じて開き直す |
| Azureポータルでは見えるがEntraでは見えない（または逆） | ポータル混在による整合性の崩れ | どちらで作成・編集したかを確認 | 以後 Entra に統一し、必要なら作り直す |
| 作成自体が失敗する | 権限不足／テナント間違い | ディレクトリ・管理ロールを確認 | 管理者権限で実施、External tenant を選び直す |
手順：アプリ登録（CIAMアプリ）の設定を整える
ユーザーフローが正常でも、アプリ登録側の設定が不足していると、テストでトークンが返らない／リダイレクトできないなどの問題が起こります。最低限、次の2点は必ず押さえます。
- Redirect URI：ユーザーフローのテストで指定するリダイレクト先と一致させる
- ID tokens の許可：ポータルテストで id_token を受け取るために必要
アプリ登録の設定ポイント
| 設定項目 | 場所 | 推奨（テスト目的） | よくあるミス |
|---|---|---|---|
| Redirect URI | App registrations → Authentication | テスト用に jwt.ms を追加（運用ではアプリのURL） | 末尾スラッシュ違い、http/https違い、ポート番号違い、別アプリを選んでいる |
| ID tokens | Authentication → Implicit grant and hybrid flows | ID tokens を ON | Access tokens だけ ON、または両方 OFF |
| アカウント種別（テナントの前提） | App registrations → Overview | External tenant（顧客）向けの構成になっている | 社内テナント前提の設定のまま進めている |
Redirect URI を合わせるときの考え方
「ユーザーフローのテスト画面で指定する Reply URL（Redirect URI）」と「アプリ登録（Authentication）に登録してある Redirect URI」はセットです。どちらか片方だけを直しても、リダイレクトエラーやトークン未取得が残ります。
この2つは完全一致している必要があります（プロトコル、ホスト、パス、末尾スラッシュ、ポート番号まで一致）。
手順：User flow を実行して jwt.ms でトークンを確認する
最後に「jwt.ms で見える状態」を作ります。ポイントはResponse type を id_tokenにすることと、アプリ登録で ID tokens が許可されていることです。
- Entra管理センターで対象の User flow を開く
- Run user flow（テスト／実行）を選ぶ
- アプリケーションとして、設定済みのアプリ登録（CIAMアプリ）を選択
- Reply URL（Redirect URI）を正しいものにする（例：jwt.ms を使うならアプリ登録にも追加済みであること）
- Response type（応答タイプ）を id_token にする
- 実行してサインインし、返ってきた ID トークンを jwt.ms で確認する
jwt.ms で「何も出ない」時に見るポイント
| 症状 | 原因候補 | 確認する場所 | 対処 |
|---|---|---|---|
| サインインは完了するが jwt.ms が空 | id_token が返っていない | Run user flow の Response type | id_token を選び直す |
| エラーで止まる（redirect_uri mismatch 等） | Redirect URI 不一致 | アプリ登録 Authentication | Redirect URI を一致させる |
| Response type に id_token が選べない／返ってこない | ID tokens 許可が OFF | Authentication → Implicit grant and hybrid flows | ID tokens を ON |
| トークンはあるが内容が期待と違う | ユーザーフロー／アプリの取り違え | issuer、policy名、aud を確認 | External tenant・対象フロー・アプリを揃える |
よくある落とし穴：External tenant ならではの追加チェック
上の2大原因で解決しない場合、External tenant（CIAM）特有の“うっかり”を疑います。多くは「違うものを見ている」系の問題です。
ディレクトリ（テナント）の取り違え
ブラウザに複数テナントのセッションが残っていると、意図せず社内テナント（Internal）側の画面を見てしまうことがあります。User flows の一覧やアプリ登録が「存在しない」ように見える時は、まず右上のディレクトリ表示を確認してください。
アプリ登録の取り違え（似た名前問題）
External tenant 側と Internal tenant 側で似た名前のアプリを作っていると、テストで別アプリを選びやすくなります。Run user flow で選択したアプリのApplication (client) IDが、今開いているアプリ登録と一致しているかを確認すると、取り違えが早く見つかります。
ブラウザ拡張・追跡防止でリダイレクトが崩れる
広告ブロッカーや追跡防止の拡張機能が強い環境では、ログイン後の遷移が途中で止まったり、リダイレクトURLのフラグメント（#以降）が欠落したりすることがあります。切り分けとして、拡張機能をOFFにしたブラウザや InPrivate で試すと原因が見えます。
運用目線のおすすめ：正常系を「テンプレ化」しておく
External tenant の検証は、環境やブラウザの状態に左右されやすいのが現実です。そこで、次のように“正常系テンプレ”を決めておくと、問題が起きた時に復旧が早くなります。
- 管理はEntra 管理センター固定（URLもブックマークして迷わない）
- テスト用アプリ登録を1つ用意し、Redirect URI に jwt.ms と localhost（検証用）を事前登録
- テスト用ユーザーフローは最小構成で1つ作り、まずそれで ID トークンが取れることを確認
- 本番アプリは認可コード + PKCE を基本とし、Implicit は必要な時だけ有効化
実施手順（まとめ）
最後に、今回の問題を最短で解消するための手順をまとめます。迷ったらこの順番で実施してください。
- entra.microsoft.com にサインインし、対象のExternal tenantを選択
- User flows の作成・確認・テストはEntra 管理センター側だけで実施（Azureポータルで操作しない）
- アプリ登録（CIAMアプリ）のRedirect URIを正しく設定（テスト時の Reply URL と一致）
- アプリ登録の Authentication でImplicit grant and hybrid flows の「ID tokens」を ON
- ユーザーフローのテスト時にResponse type を id_tokenにして実行
- 返ってきた ID トークンをjwt.msで確認
まとめ：直すポイントは「ポータル統一」と「id_token」
External tenant（Entra External ID / CIAM）で「ユーザーフローが作れない／一覧に出ない」「jwt.ms でトークンが見られない」は、次の2点を押さえるだけで解消することが多いトラブルです。
- 操作はentra.microsoft.com（Entra 管理センター）に統一し、Azureポータルと行き来しない
- User flow のテストでResponse type を id_tokenにし、アプリ登録でID tokens を許可する
まずは jwt.ms で ID トークンが見える「正常系」を作ってください。正常系ができれば、以降の調整（属性・クレーム・ユーザー体験の設計）もスムーズに進みます。
コメント