Azure App Service や Azure Functions で Microsoft Entra 認証を使っている場合、今すぐ確認すべきポイントは「テナント種別」「アプリ登録」「発行者 URL」「許可されたトークン対象ユーザー」「認証と認可の分離」「シークレット管理」「Microsoft Graph 移行」です。特に、ログインできるかどうかだけで判断すると、意図しないテナントやクライアントアプリからのアクセスを許してしまう可能性があります。
本記事では、2026年5月20日時点で確認できる Microsoft Learn の公式情報をもとに、Azure App Service / Azure Functions で Microsoft Entra サインインを構成する際の変更点、影響範囲、管理者・開発者が確認すべき設定を整理します。なお、対象の Microsoft Learn ページの表示上の最終更新日は 2026年4月27日です。(Microsoft Learn)
Microsoft Entra認証でまず確認すべき結論
Microsoft Entra 認証の設定は、単に「ログイン画面を出す」だけの機能ではありません。App Service Authentication、いわゆる Easy Auth を使うと、アプリ側で認証処理を大きく実装しなくてもサインインを構成できます。一方で、認証後に誰へアクセスを許可するか、どのトークンを受け入れるか、どのテナントを信頼するかは、アプリの用途に合わせて明確に決める必要があります。App Service の組み込み認証は、リクエストがアプリケーションコードへ到達する前に認証処理を行い、認証情報を HTTP ヘッダーとしてアプリへ渡します。(Microsoft Learn)
| 確認項目 | 影響 | 管理者・開発者が行うこと |
|---|---|---|
| テナント種別 | 社内ユーザー向けか、外部顧客向けかで構成が変わる | Workforce configuration と External configuration を使い分ける |
| アプリ登録 | 同意、権限、トークンの発行先に影響する | 自動作成か既存登録の利用かを決める |
| 発行者 URL | 古い issuer のままだとベストプラクティスから外れる | https://login.microsoftonline.com/<tenant-id>/v2.0 を確認する |
| Allowed token audiences | 受け入れるアクセストークンの aud を制限できる | App ID URI やカスタム URI を使う API で明示設定する |
| 認可 | 認証済みでもアクセス許可済みとは限らない | ロール、テナント、クレームをアプリ側または組み込みポリシーで検証する |
| シークレット | 有効期限切れや漏えいリスクがある | Key Vault 参照またはマネージド ID 利用を検討する |
| Microsoft Graph 移行 | Azure AD Graph 依存は移行対象 | graph.windows.net 参照や旧スコープを見直す |
影響範囲はApp ServiceとAzure Functionsの認証設定
今回の公式情報の対象は、Azure App Service または Azure Functions の認証で Microsoft ID プラットフォーム、つまり Microsoft Entra を ID プロバイダーとして使う構成です。対象になるのは、社内向け Web アプリ、API、Functions、外部顧客向けアプリ、ネイティブクライアントやデーモンアプリから呼び出されるバックエンド API などです。(Microsoft Learn)
影響を受けやすいのは、次のような環境です。
- App Service Authentication を有効にしている Web アプリ
- Azure Functions で Microsoft Entra 認証を使っている API
- 複数のデプロイスロットを使っている本番・ステージング環境
- App Service の前段に Azure Front Door やリバースプロキシを置いている環境
- 複数テナントのユーザーを受け入れる SaaS 型アプリ
- ネイティブアプリ、SPA、バッチ、デーモンアプリから App Service API を呼び出す構成
- 旧 Azure AD Graph に依存している既存アプリ
注意したいのは、認証設定の見直しが「すぐに全環境で障害を起こす変更」とは限らない点です。むしろ、現在動いている環境でも、設定が広すぎる、古い issuer を使っている、シークレット更新に依存している、Graph 移行が未完了といったリスクが残っている可能性があります。
テナント選択は「社内向け」か「外部顧客向け」かで決める
Microsoft Entra 認証を構成する最初の分岐は、アプリをどのテナントに登録するかです。公式手順では、従業員やビジネスゲスト向けなら Workforce configuration、コンシューマーやビジネス顧客向けなら External configuration を選ぶ流れになっています。(Microsoft Learn)
| 利用者の想定 | 選ぶ構成 | 実務上の判断基準 |
|---|---|---|
| 自社社員のみ | Workforce configuration | 単一テナントで管理しやすい。社内業務アプリに向く |
| 自社社員＋取引先ゲスト | Workforce configuration | ゲストユーザー管理や条件付きアクセスと合わせて設計する |
| 一般消費者 | External configuration | メール、ワンタイムパスコード、外部 ID プロバイダーなどの設計が必要 |
| 複数企業の顧客 | External configuration またはマルチテナント構成 | テナント検証と契約済み組織の判定が重要 |
失敗しやすいのは、社内向けアプリを「広く使えるように」とマルチテナントで作成してしまうケースです。マルチテナントにすると利用範囲は広がりますが、許可するテナントをアプリ側で検証しないと、想定外の組織からのアクセスを受け入れる設計になりかねません。
アプリ登録は自動作成でよい場合と既存登録を使う場合を分ける
App Service 認証では、アプリ登録を自動作成することも、管理者が事前に作成した既存のアプリ登録を使うこともできます。通常は自動作成で始めても問題ありませんが、権限管理やテナント構成の都合で既存登録を使うべきケースがあります。公式情報では、アプリ登録を作成する権限がない場合、アプリを含むテナントとは異なる Microsoft Entra テナントの登録を使う場合、政府機関向けクラウドで新規登録作成オプションが使えない場合などが、既存登録を使う代表例として示されています。(Microsoft Learn)
実務では、次のように判断すると分かりやすくなります。
| 状況 | 推奨される選択 | 注意点 |
|---|---|---|
| 小規模な社内 Web アプリを新規作成する | 新しいアプリ登録を自動作成 | 後から権限や同意設定を確認する |
| Entra 管理者がアプリ登録を一元管理している | 既存登録を使用 | クライアント ID、シークレット、issuer を正確に入力する |
| 外部テナントを使う | 既存登録または外部構成に合わせた登録 | アプリ本体の Azure サブスクリプションと ID 管理の責任分界を明確にする |
| 本番・検証・ステージングを分ける | 環境ごとに別のアプリ登録 | 権限や同意を環境間で共有しない |
アプリ登録を1つにまとめると管理が楽に見えますが、運用では逆にトラブルの原因になります。検証環境で追加した権限が本番にも影響する、ステージングのリダイレクト URI が本番設定に混ざる、シークレット更新のタイミングが全環境に波及する、といった問題が起こりやすくなります。
発行者URLはv2.0エンドポイントへ更新する
既存の Microsoft Entra 認証設定で特に確認したいのが、発行者 URL です。公式情報では、発行者 URL は <authentication-endpoint>/<tenant-id>/v2.0 の形式で指定し、グローバル Azure の場合は https://login.microsoftonline.com/<tenant-id>/v2.0 を使う例が示されています。高速セットアップで ID プロバイダーを作成した場合、レガシーな https://sts.windows.net エンドポイントが設定されることがあり、現在の Microsoft Entra ID のベストプラクティスに合わせて login.microsoftonline.com/<tenant-id>/v2.0 へ更新するよう案内されています。(Microsoft Learn)
確認すべき場所は、Azure portal の App Service または Functions アプリの「認証」設定です。Microsoft ID プロバイダーを編集し、issuer が古い形式になっていないかを確認します。
よくあるミスは次の3つです。
| ミス | 起きる問題 | 修正方法 |
|---|---|---|
| tenant-id が別テナントの ID | サインイン後にトークン検証で失敗する | アプリ登録のディレクトリ ID を確認する |
sts.windows.net のまま | v2.0 前提の構成や Graph 移行と噛み合わない | login.microsoftonline.com/<tenant-id>/v2.0 に更新する |
| リダイレクト URI が不足 | サインイン後にコールバックで失敗する | https://<app-name>.azurewebsites.net/.auth/login/aad/callback 形式を登録する |
本番環境で issuer を変更する場合は、いきなり本番だけを更新しないでください。ステージングスロットや検証環境で、通常ログイン、ログアウト、API 呼び出し、トークン更新、Graph 呼び出しまで確認してから展開するのが安全です。
Allowed token audiencesで受け入れるトークンを絞る
Allowed token audiences は、App Service または Azure Functions が受け入れるアクセストークンを aud クレームに基づいて制限する設定です。既定では、関連付けられたアプリ登録向けに発行されたトークンを受け入れますが、複数の API、複数のアプリケーション ID、カスタム Application ID URI を使う場合は、許可する audience を明示的に設定する必要があります。設定した場合、aud が許可リストに一致しないトークンは拒否されます。(Microsoft Learn)
例えば、バックエンド API を api://<application-client-id> で公開しているのに、App Service 側の Allowed token audiences にその値が入っていないと、クライアントアプリが正しくトークンを取得していても API 側で拒否される可能性があります。
管理者・開発者は、次の順で棚卸しすると効率的です。
| 確認順 | 確認内容 | 合格基準 |
|---|---|---|
| 1 | API を公開しているアプリ登録 | Application ID URI が把握できている |
| 2 | API を呼ぶクライアントアプリ | どの resource / scope でトークンを要求しているか分かる |
| 3 | App Service の Allowed token audiences | クライアントが取得するトークンの aud と一致している |
| 4 | 不要な audience | 使っていない古い URI が残っていない |
Allowed token audiences は、設定すれば安全になるという単純なものではありません。必要な値を入れ忘れると正当なクライアントも拒否されます。一方で、古い値や広すぎる値を残すと、過去のクライアントや想定外の経路からのアクセスを許し続ける可能性があります。
Webサイトは302、APIは401を基本に設計する
認証設定では、未認証リクエストをどう扱うかを決めます。公式情報では、Web サイトには HTTP 302 Found redirect、API には HTTP 401 Unauthorized が推奨されています。また、アクセス制限では「認証を要求する」か「未認証アクセスを許可する」かを選択できます。(Microsoft Learn)
| アプリの種類 | 未認証時の推奨動作 | 理由 |
|---|---|---|
| ブラウザで利用する業務 Web アプリ | 302 リダイレクト | ユーザーを自然にサインイン画面へ誘導できる |
| REST API | 401 Unauthorized | API クライアントが認証エラーとして処理しやすい |
| 一部ページだけ公開するサイト | 未認証アクセスを許可し、アプリ側で制御 | トップページやヘルスチェックを公開できる |
| 存在自体を隠したい管理 API | 404 Not found も選択肢 | セキュリティ設計上の意図がある場合のみ使う |
SPA や API で 302 を返すと、クライアントが HTML のログインページを受け取ってしまい、JSON として処理しようとして失敗することがあります。逆に、通常の Web サイトで 401 を返すと、利用者は「ログインすればよい」と分からず離脱しやすくなります。
トークンストアも確認対象です。公式情報では Token store が推奨されており、アプリケーションのトークンを収集、保存、更新できます。ただし、アプリ側でトークンを使わない場合やパフォーマンス最適化が必要な場合は、後から無効化する選択肢もあります。(Microsoft Learn)
認証と認可を混同しない
App Service Authentication を有効にすると、サインイン済みかどうかはプラットフォーム側で判定できます。しかし、それだけで「誰が何にアクセスできるか」まで完成するわけではありません。公式情報でも、App Service 認証は既定では認証を扱い、認可は別のステップだと説明されています。さらに、作成されたアプリ登録では既定でテナント内のすべてのユーザーがアプリにアクセスできるため、必要に応じて追加の認可判断が必要です。(Microsoft Learn)
特にマルチテナントアプリでは注意が必要です。公式情報では、App Service 認証をマルチテナントシナリオで構成した場合、要求がどのテナントから来たかを検証しないため、アプリ側で issuer と tenant ID を検証する必要があると説明されています。(Microsoft Learn)
アプリコードで認可を行う場合、App Service 認証が挿入する x-ms-client-principal ヘッダーや、x-ms-token-aad-access-token ヘッダーを利用できます。ただし、クレーム名はマッピングされることがあるため、トークン内の tid がそのまま tid として見えるとは限りません。公式情報では、tid が http://schemas.microsoft.com/identity/claims/tenantid にマップされる例が示されています。(Microsoft Learn)
組み込み認可ポリシーを使う場合の注意点
App Service 認証には、特定のクライアントアプリ、特定のプリンシパル、特定のテナントに絞るための組み込みチェックもあります。ただし、公式情報では、これらの組み込みチェックの構成は現時点で Azure Resource Manager テンプレートまたは REST API を使う必要があるとされています。(Microsoft Learn)
代表的な設定は次のとおりです。
| 設定 | 目的 | 注意点 |
|---|---|---|
allowedApplications | 特定のクライアントアプリから取得されたトークンのみ許可 | appid または azp クレームを評価する |
allowedPrincipals.identities | 特定のユーザーまたはアプリの Object ID のみ許可 | ID 一覧には合計文字数制限がある |
WEBSITE_AUTH_AAD_ALLOWED_TENANTS | 最大10個のテナント ID に制限 | マルチテナント SaaS で有効 |
WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL | oid クレームを必須にする | アプリケーション主体の検証に使う |
これらのチェックに失敗したリクエストは HTTP 403 Forbidden になります。403 が出たときは、単なるログイン失敗ではなく、トークンは認証されたが認可チェックで落ちた可能性を疑ってください。
クライアントシークレットはスロット固定設定として扱う
App Service 認証で新しいアプリ登録を作成すると、クライアントシークレットは MICROSOFT_PROVIDER_AUTHENTICATION_SECRET というスロット固定のアプリケーション設定として保存されます。既存のアプリ登録を使う場合も、クライアントシークレットは推奨されており、シークレットが設定されていない場合は OAuth 2.0 の暗黙的な許可フローが使われますが、公式情報では推奨されていません。(Microsoft Learn)
スロット固定であることは重要です。認証設定は環境に紐づくため、本番とステージングで同じシークレットや同じアプリ登録を共有すると、スロットスワップ時に予期しない認証不整合が起きる可能性があります。App Service 認証の API バージョン管理に関する公式情報でも、V1 から V2 へ移行する際は、シークレットをスロット固定のアプリケーション設定へ移す必要があると説明されています。(Microsoft Learn)
確認時は、次の観点で棚卸しします。
| 確認項目 | 良い状態 | 危険な状態 |
|---|---|---|
| シークレット保存先 | App Service のスロット固定設定、または Key Vault 参照 | 平文を手順書やローカルファイルに保存 |
| 有効期限 | 更新予定が管理されている | 期限切れ直前まで検知できない |
| 環境分離 | 本番・検証で別の登録とシークレット | 全環境で同一シークレット |
| 権限 | アプリごとに必要最小限 | 複数アプリで権限と同意を共有 |
Azure CLI で設定を確認する場合は、出力に機密情報が含まれる可能性を前提に扱ってください。公式情報でも、シークレット値は重要なセキュリティ資格情報であり、共有したりローカルに永続化したりしないよう注意されています。(Microsoft Learn)
az webapp auth show -g <resource-group> -n <app-name>マネージドIDを使うとシークレット管理の負担を減らせる
公式情報では、クライアントシークレットの代わりにマネージド ID を使う構成も説明されています。シークレットの代わりに ID を使うと、シークレットの有効期限対応や漏えいリスクを減らせます。この方式では、ユーザー割り当てマネージド ID とフェデレーション ID 資格情報を利用し、クライアントシークレットの代わりにクライアントアサーションとして使います。ただし、この方式は Workforce configuration でのみ利用できるとされています。(Microsoft Learn)
移行の流れは、概ね次のようになります。
| 手順 | 作業 | 注意点 |
|---|---|---|
| 1 | ユーザー割り当てマネージド ID を作成する | 使い回し前提で作らない |
| 2 | App Service または Functions に割り当てる | 対象アプリ以外へ不要に割り当てない |
| 3 | Object ID と Client ID を控える | 後続手順で使い分ける |
| 4 | アプリ登録にフェデレーション ID 資格情報を構成する | アプリコード更新手順は不要な場合がある |
| 5 | OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID を追加する | 値はマネージド ID の Client ID。アプリ登録の Client ID ではない |
| 6 | Client secret setting name を上記設定名に変更する | スロット固定にする |
| 7 | サインイン動作を検証し、既存シークレットを削除する | 検証前に削除しない |
特に間違えやすいのが、OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID にアプリ登録のクライアント ID を入れてしまうケースです。公式手順では、ここに入れるのはマネージド ID の Client ID であり、アプリ登録の Client ID ではないと明記されています。(Microsoft Learn)
クライアントアプリからAPIを呼ぶ場合は追加設定が必要
App Service や Functions を単にユーザーサインイン付きの Web アプリとして使うだけなら、クライアントアプリ登録の設定は不要な場合があります。一方、ネイティブアプリやデーモンアプリから App Service の API を呼び出す場合は、クライアント側のアプリ登録と API 権限の設計が必要です。公式情報では、ネイティブクライアントはサインインユーザーの代わりに API へアクセスでき、デーモンアプリはユーザーではなくアプリ自身の ID でトークンを取得できると説明されています。(Microsoft Learn)
| クライアント種別 | 主な用途 | 必要な確認 |
|---|---|---|
| ネイティブクライアント | デスクトップ、モバイルアプリ | user_impersonation の委任アクセス許可 |
| デーモンアプリ | バッチ、ジョブ、サービス間通信 | クライアント資格情報フロー、アプリロール、管理者同意 |
| SPA | ブラウザ上のフロントエンド | API の audience、CORS、未認証時のレスポンス |
| サーバーサイド Web アプリ | 別の App Service API 呼び出し | トークン取得方式とロール検証 |
デーモンアプリでは特に注意が必要です。公式情報では、クライアント資格情報を使う方式により、Microsoft Entra テナント内のすべてのクライアントアプリケーションがアクセストークンを要求してターゲットアプリへ認証できる可能性があるため、特定のクライアントだけを許可するには追加構成が必要だと説明されています。具体的には、保護対象のアプリ登録にアプリロールを定義し、クライアント側へアプリケーション権限を付与し、管理者の同意を与えます。ただし、App Service 認証は roles クレームの検証までは行わないため、期待するロールを持っているかはアプリコード側で確認する必要があります。(Microsoft Learn)
V1 API利用環境はV2移行とスロット設定を確認する
App Service 認証には管理 API の V1 と V2 があり、公式情報では Azure portal の認証エクスペリエンスには V2 が必要とされています。V1 を使っているアプリは移行できますが、シークレット構成をスロット固定のアプリケーション設定へ移す必要があります。また、V2 への移行は元に戻せず、一部の既存クライアントから認証・認可機能を管理できなくなる可能性があるため、事前確認なしに本番環境へ適用すべきではありません。(Microsoft Learn)
V1/V2 周りで確認すべきポイントは次のとおりです。
| 確認項目 | 対応 |
|---|---|
| Azure portal に Upgrade ボタンが表示されるか | V1 モデルの可能性があるため、移行手順を確認する |
| シークレットがアプリ設定へ移っているか | スロット固定設定として管理する |
| Microsoft Account プロバイダーを個別利用しているか | Microsoft ID プラットフォーム側へ移行できるか検討する |
自動化スクリプトが /authsettings を使っているか | /authsettingsV2 への移行影響を確認する |
| スロットスワップを行うか | 認証設定とシークレットが環境をまたいで混ざらないようにする |
認証ミドルウェアのランタイムバージョンは、通常は最新を使います。公式情報では、まれに自動更新で問題が起きた場合に runtimeVersion で一時的に特定バージョンへピン留めできると説明されています。ただし、ピン留めは恒久対応ではなく、原因調査と修正までの一時措置として扱うべきです。(Microsoft Learn)
Azure AD Graph依存はMicrosoft Graphへ移行する
古いアプリでは、グループメンバーシップ確認やユーザー情報取得のために Azure AD Graph を使っている場合があります。公式情報では、古いアプリが Azure AD Graph に依存している可能性があり、Microsoft Graph へ移行する必要があると説明されています。App Service 認証側では、Microsoft Graph のアクセス許可をアプリ登録に追加したうえで、issuer に /v2.0 を含める、サインイン構成から Azure AD Graph のアクセス許可要求を削除する、https://graph.windows.net への参照を削除する、といった対応が必要です。(Microsoft Learn)
Microsoft Graph への移行では、次のサインインパラメーターが例として示されています。
scope=openid profile email https://graph.microsoft.com/.defaultMicrosoft Graph の公式移行情報では、Azure AD Graph は非推奨であり、2025年8月31日に extended access が終了し、fully retired と示されています。既存アプリでまだ graph.windows.net、Azure AD Graph 用スコープ、古い SDK、グループ確認の独自実装が残っている場合は、認証設定だけでなくアプリコードも含めて移行計画を立てる必要があります。(Microsoft Learn)
展開前に必ずテストすべきシナリオ
Microsoft Entra 認証の設定変更は、ログイン画面が表示されるかどうかだけで完了判定しないでください。展開前には、最低でも次のテストを行います。
| テスト | 期待結果 |
|---|---|
| 未認証ユーザーで Web にアクセス | Web アプリなら 302 でサインインへ誘導される |
| 未認証クライアントで API にアクセス | API なら 401 が返る |
| 許可されたユーザーでログイン | アプリ画面または API に正常アクセスできる |
| 許可されていないユーザーでログイン | 認証後でもアクセスが拒否される |
| 許可されたテナントからアクセス | tid または issuer 検証を通過する |
| 許可されていないテナントからアクセス | アプリ側または組み込みポリシーで拒否される |
| 正しい audience のトークンで API 呼び出し | 成功する |
| 古い audience のトークンで API 呼び出し | 拒否される |
| デーモンアプリで API 呼び出し | 必要なアプリロールがある場合だけ成功する |
| ステージングから本番へスワップ | 認証シークレットやリダイレクト URI が混在しない |
障害時の切り分けでは、まず HTTP ステータスを見ます。302 はリダイレクト、401 は未認証、403 は認可チェック失敗の可能性が高い状態です。次に、App Service の認証ログ、アプリケーションログ、トークンの aud、iss、tid、oid、roles を確認します。
管理者と開発者の確認チェックリスト
最後に、実務でそのまま使える確認項目を整理します。
| 担当 | 確認すること | 完了基準 |
|---|---|---|
| Entra 管理者 | アプリ登録の所有者、権限、同意 | 不要な権限がなく、所有者が明確 |
| Azure 管理者 | App Service の認証設定 | ID プロバイダー、issuer、未認証時動作が用途に合っている |
| 開発者 | アプリコードの認可処理 | ロール、テナント、ユーザー属性を必要に応じて検証している |
| 開発者 | API の audience | クライアントが取得するトークンの aud と一致している |
| 運用担当 | シークレット期限 | 更新手順と期限監視がある |
| 運用担当 | マネージド ID 移行可否 | Workforce configuration で利用可能か確認済み |
| 全員 | Graph 移行 | graph.windows.net や Azure AD Graph 依存が残っていない |
| 全員 | 環境分離 | 本番、検証、スロットでアプリ登録と権限を共有していない |
Microsoft Entra 認証の見直しでは、まず現在の App Service 認証設定を棚卸しし、次に issuer、Allowed token audiences、テナント制限、クライアントシークレット、Graph 依存を確認します。そのうえで、ステージング環境でログイン、API 呼び出し、許可・拒否パターンをテストし、本番へ展開してください。
認証は「ログインできる」だけでは不十分です。誰が、どのテナントから、どのクライアントアプリを経由して、どの API にアクセスできるのかを明確にすることが、Azure App Service と Microsoft Entra 認証を安全に運用するための最短ルートです。
コメント