Microsoft Entra External IDでテナントを用意し、ユーザーフローとブランディングまで整えたら、いよいよ最後の仕上げです。それが自分のアプリに、安全なサインインを組み込むという工程ですね。ここまでで作った「顧客がサインインする画面」を、実際のWebアプリやモバイルアプリとつなぎ込み、さらに多要素認証（MFA）や条件付きアクセスで守りを固めていきます。
ところが、いざMicrosoft Learnの公式ドキュメントを開くと、OIDC・SAML・リダイレクトURI・クレーム・カスタム拡張……と、いきなり用語の壁が立ちはだかります。私自身、最初にアプリ登録の画面を開いたとき「リダイレクトURIって何を入れればいいの？」で数十分固まりました。
「アプリとExternal IDって、どうやってつなぐの？OIDCとSAMLはどっちを選べばいいの？外部ユーザーにもMFAって効かせられるの？」
この記事では、External IDのアプリ統合（OIDCとSAML）、外部ユーザーへのMFA適用、条件付きアクセスによるアクセス制御、そして少し進んだAPIコネクタ／カスタム拡張による外部検証の差し込みまでを、公式の正確さは押さえつつ、初心者がつまずく所を日本語で噛み砕いて解説します。読み終わるころには、顧客向けアプリに「安全なサインイン」を自分で組み込めるようになります。これがExternal IDシリーズの締めの記事です。
なお、そもそもExternal IDが何者なのか、B2BとCIAMの違いやテナントの使い分けがあやふやな方は、先に Microsoft Entra External IDとは？ に目を通しておくと、この記事の位置づけがはっきりします。本記事はそのシリーズの中で「アプリ統合とセキュリティ」を深掘りする子記事です。
全体像：サインイン画面と「アプリ本体」をつなぐ
手を動かす前に、これから何をするのか全体像を掴んでおくと迷いません。イメージとしては、受付（External ID）とお店の中（あなたのアプリ）を橋渡しする作業だと考えてください。
External IDが用意するのは「本人確認をして、通行証を発行してくれる受付」です。顧客がメールアドレスやパスワード、ソーシャルアカウントでサインインすると、External IDが本人確認を済ませ、トークンという通行証を発行します。あなたのアプリは、その通行証を受け取って「この人は確かに本人だ」と信頼し、中に通す。この受け渡しのルールを取り決めるのがアプリ統合です。
そして通行証を受け渡すときの「言語（プロトコル）」が2種類あります。それがOIDC（OpenID Connect）とSAMLです。まずはこの2つの使い分けからいきましょう。
アプリ統合：OIDCとSAMLを使い分ける
OIDCとSAML、どちらも「サインインを外部（External ID）に任せる」という目的は同じです。違うのは登場した時代と得意な相手。判断基準はシンプルで、これから作るモダンなアプリならOIDC、既存のエンタープライズ製品につなぐならSAMLと覚えておけば、9割はそれで正解です。
OIDC：これから作るアプリの標準
OIDCは、OAuth 2.0という認可の仕組みの上に「本人確認（認証）」を乗せた、比較的新しくて軽量なプロトコルです。JSONとHTTPSでやり取りするので、SPA（React/Vueなどのフロントエンド）・モバイルアプリ・APIといったいまどきのアプリと相性が抜群。External IDのCIAMシナリオでも、基本はこのOIDCが主役になります。
手順の入り口は Microsoft Entra管理センターでのアプリ登録です。External IDのテナントに切り替えたうえで、「アプリケーション」→「アプリの登録」→「新規登録」と進みます。ここで入力するのは主に3つ。
- 名前：管理用の表示名。あとから変更できるので気楽に。
- サポートされるアカウントの種類：External ID（顧客向け）では、この外部テナントのユーザーを対象にする選択肢を選びます。
- リダイレクトURI：ここが最初の関門です。
リダイレクトURIとは、「本人確認が終わったあと、トークン（通行証）を送り返す先」のことです。受付で本人確認が済んだお客さんを、あなたのお店のどの入口に案内するか、その住所を指定するイメージですね。たとえばローカルで開発中のSPAなら http://localhost:3000/、公開後なら https://yourapp.com/auth/callback のように、アプリ側で「サインイン後に戻ってくるページ」のURLを登録します。
ここでプラットフォーム（SPA / Web / モバイル）の選択を間違えると、あとで redirect_uri_mismatch や「クライアントシークレットが必要です」といったエラーに悩まされます。SPAなのにWebアプリとして登録してしまうと、本来不要なはずのシークレットを求められて混乱する、というのは私も踏んだ落とし穴です。「フロントエンドだけで動く＝SPA」「サーバー側で処理する＝Web」と、アプリの構造に合わせて選んでください。
登録が終わると、アプリケーション（クライアント）IDとディレクトリ（テナント）IDが発行されます。この2つと、先ほど作ったユーザーフローの情報を、アプリ側の認証ライブラリ（Microsoftが提供するMSALなど）に設定すれば、あとはライブラリが「サインイン画面への誘導 → トークンの取得 → 保管」まで面倒を見てくれます。ゼロから認証を自前実装しなくていい、というのがこの仕組みの一番おいしいところです。
「クライアントIDとテナントID、リダイレクトURI」。まずはこの3点セットをアプリに渡す、と覚えれば迷いません。
SAML：既存のエンタープライズアプリにつなぐ
一方のSAMLは、OIDCより前から使われてきた「老舗」のプロトコルです。XMLベースで、企業向けのSaaS（Salesforce、Workday、社内の業務パッケージなど）が古くからサポートしています。すでにSAMLにしか対応していない既存製品と連携したいときは、こちらを選ぶことになります。
SAMLでのSSO（シングルサインオン）は、アプリ登録ではなくエンタープライズアプリケーションから構成します。管理センターで「エンタープライズアプリケーション」→「新しいアプリケーション」を開き、ギャラリーから該当製品を探すか、なければ「独自のアプリケーションの作成」で登録します。追加後、そのアプリの「シングルサインオン」を開いて「SAML」を選ぶのが起点です。
ここでの作業は、ざっくり言うとEntra側とアプリ側で「合言葉」を交換することです。具体的には次の値をお互いに登録し合います。
- 識別子（Entity ID）：そのアプリを一意に表すID。
- 応答URL（Assertion Consumer Service URL）：OIDCのリダイレクトURIに相当する「戻り先」。
- フェデレーションメタデータ／署名証明書：Entra側が発行し、アプリ側に登録してもらう「本物である証明」。
SAMLは、この識別子と応答URLの1文字違いや、証明書の登録忘れでハマりがちです。多くのSaaSには「Entra ID（Azure AD）との連携手順」という公式ドキュメントが用意されているので、その製品側の手順とEntra側の画面を並べて、値を突き合わせながら埋めるのが確実です。逆に言えば、これから自分でゼロからアプリを作るなら、わざわざSAMLを選ぶ理由はほぼありません。素直にOIDCでいきましょう。
外部ユーザーにMFAを適用する
アプリとつながったら、次は守りです。まず入れておきたいのがMFA（多要素認証）。パスワードだけでなく「本人しか受け取れない2つ目の要素」を要求することで、パスワードが漏れても不正ログインを防ぐ、あの仕組みですね。
ここで初心者がよく誤解するのが「MFAは社内ユーザー向けの機能で、顧客（外部ユーザー）には効かせられないのでは？」という点です。結論から言うと、External IDでも外部ユーザーにMFAを適用できます。しかも顧客向けシナリオでは、SMSよりメールワンタイムパスコード（メールにコードを送る方式）が扱いやすく、External IDの標準的な選択肢として用意されています。
適用の考え方は「ユーザー個人に設定する」のではなく、ポリシーで一括にかけるのが基本です。External IDでは、次に説明する条件付きアクセスのポリシーとして「サインイン時にMFAを要求する」を有効化する、という流れになります。つまりMFAと条件付きアクセスは地続きで、「どういう条件のときに」「MFAを求めるか」をセットで決めていく、と捉えると理解が早いです。
なお、全ユーザーに常時MFAを求めると、ちょっとログインするだけの顧客には煩わしく感じられ、離脱の原因にもなります。だからこそ「いつMFAを求めるか」を柔軟に決められる条件付きアクセスが効いてくるわけです。
条件付きアクセスで「状況に応じた制御」をかける
条件付きアクセスは、ひとことで言えば「もし〜なら、〜する」というアクセス制御の自動ルールです。サインインの状況（誰が、どのアプリに、どこから、どんなデバイスで）を見て、そのまま通すか、MFAを求めるか、ブロックするかを自動で判断してくれます。
身近なたとえで言うと、マンションのオートロックのようなものです。住人（いつもの環境）ならそのまま通すけれど、見慣れない相手（普段と違う国・怪しいIP）なら、もう一段の本人確認（MFA）を求める。人手をかけずに、状況に応じて守りの強さを自動で変えられるのが強みです。
External IDでの条件付きアクセスも、管理センターの「保護」→「条件付きアクセス」から作ります。ポリシーは大きく「割り当て（条件）」と「アクセス制御（結果）」の2部構成です。
- ユーザー：誰に効かせるか（例：全顧客ユーザー、特定のグループ）。
- ターゲットリソース：どのアプリに対して効かせるか（先ほど登録したアプリ）。
- 条件：どんなときに（サインインリスク・場所・デバイスなど）。
- アクセス制御（結果）：MFAを要求する／アクセスをブロックするなど。
たとえば「顧客がサインインするときはメールワンタイムパスコードでMFAを要求する」というポリシーを作れば、先ほどのMFAが実際にアプリのサインインに効くようになります。
ここで絶対にやってほしい注意があります。条件付きアクセスは、設定を誤ると自分も含めて全員がログインできなくなる（締め出し）という事故が起きます。ポリシーを作るときは、いきなり全員に「有効」で適用せず、まず「レポート専用」モードで様子を見るか、テスト用の少人数グループだけを対象にして挙動を確認してから広げてください。私は検証テナントで一度、自分をブロックする条件を書いてしまい冷や汗をかきました。管理者は除外設定を入れておくのが鉄則です。
なお、条件付きアクセスはMicrosoft Entra ID P1以上を前提とする有償機能です。学習で試すなら評価版テナントを使うと費用をかけずに触れます。
APIコネクタ／カスタム拡張で外部検証を差し込む
最後は少し進んだ話です。External IDには、サインアップやサインインの途中に、自分で用意した処理（API）を割り込ませる仕組みがあります。これがAPIコネクタ／カスタム拡張（カスタム認証拡張機能）です。
何が嬉しいのか、具体例で考えましょう。たとえば――
- サインアップ時に、入力された会社コードが自社の顧客DBに存在するかを確認したい。
- 登録時に、外部の与信サービスやメール検証サービスに問い合わせて可否を判断したい。
- トークンに、External IDが持っていない独自の属性（会員ランクなど）を追加してからアプリに渡したい。
こうした「External IDの標準機能だけでは足りない、自社独自のロジック」を差し込むのが、この仕組みの役割です。イメージとしては、受付が通行証を発行する直前に、自社の担当者にひと声かけて確認を取るようなもの。External IDが認証フローの特定のタイミング（たとえばトークン発行前）で、あなたが指定したエンドポイント（Azure Functionsなどで用意したAPI）を呼び出し、その応答を受けて処理を続けます。
設定の流れはおおまかに次の通りです。まず呼び出し先のAPIを用意し（Azure Functionsが定番）、管理センターでカスタム認証拡張機能を登録してそのエンドポイントを指し、認証時にExternal IDからの呼び出しを受け付けられるよう認証（アプリの権限付与）を設定します。そのうえで、ユーザーフローの中で「このタイミングでこの拡張を呼ぶ」と紐づける、という段取りです。
ここは一気に難易度が上がる領域なので、いきなり本番で凝ったことをせず、まずは「トークン発行前にAPIを呼んで、固定の属性を1つ足すだけ」といった最小構成で動きを体験するのがおすすめです。呼び出しのリクエスト・レスポンスの形式（JSONで何が渡ってきて、何を返すか）さえ掴めれば、あとは中身のロジックを育てていくだけになります。External IDの「拡張ポイント」の存在を知っているかどうかで、実現できる要件の幅が大きく変わってくる部分です。
まとめ：顧客向けアプリに安全なサインインを組み込む
この記事では、External IDのアプリ統合とセキュリティを、つなぐ→守る→拡張する、という順で見てきました。要点を振り返っておきます。
- アプリ統合：これから作るモダンなアプリはOIDC（アプリ登録＋リダイレクトURI＋クライアント/テナントID）、既存のエンタープライズ製品はSAML（エンタープライズアプリでSSO構成）。迷ったらOIDC。
- リダイレクトURI／プラットフォーム選択がOIDCの最初の関門。SPAとWebの取り違えに注意。
- MFA：外部ユーザーにも適用可能。顧客向けはメールワンタイムパスコードが扱いやすい。
- 条件付きアクセス：「もし〜なら〜する」の自動ルールでMFA要求やブロックを制御。締め出し事故に注意し、レポート専用や少人数で検証してから展開。P1が前提。
- APIコネクタ／カスタム拡張：認証フローに自社独自の処理を差し込む拡張ポイント。まずは最小構成で体験を。
ここまでできれば、顧客がメールやソーシャルで安全にサインインし、必要に応じてMFAで守られ、自社独自の検証も通ったうえでアプリを使える――という、CIAMの一連の仕組みを自分の手で組み上げられるようになったはずです。External IDシリーズは、これで「概要 → ユーザーフロー／ブランディング → アプリ統合とセキュリティ」と一周しました。あとは実際の評価版テナントで、手を動かしながら固めていってください。
あわせて読みたい：
