Azure App ServiceでMicrosoft Entra認証を使っている場合、2026年4月更新で最優先に確認すべきなのは、Allowed token audiences、Issuer URL、クライアントシークレットの扱い、認証と認可の分離です。特に2026年4月24日の差分では、受け入れるアクセストークンのaudクレームを制御する「Allowed token audiences」の説明が追加され、App ServiceやAzure FunctionsをAPIとして公開している環境では見直しの優先度が高くなりました。(GitHub)
なお、Microsoft Learnの該当ページは表示上「2026年4月27日」が最終更新日になっています。GitHub履歴では、4月24日にAllowed token audiencesの節が追加され、4月27日にマネージドID認証に関するプレビュー表記を外す変更が入っています。本記事では、4月24日の更新を軸にしながら、公開時点で反映されている4月27日の差分も含めて実務向けに整理します。(Microsoft Learn)
Azure App Service Microsoft Entra Authenticationの2026年4月更新で押さえるべきこと
Microsoft公式ドキュメント「Configure Microsoft Entra Authentication – Azure App Service」は、Azure App ServiceまたはAzure FunctionsでMicrosoft Entra IDサインインを構成するための手順を説明しています。App Serviceの組み込み認証は、アプリ側に大きな認証コードを追加せずに、Microsoft Entra、Google、GitHub、OpenID ConnectなどのIDプロバイダーと連携できる機能です。(Microsoft Learn)
今回の更新で、security admins、identity teams、compliance teamsが特に見るべきポイントは次の通りです。
| 更新・確認ポイント | 実務上の意味 | まず確認すること |
|---|---|---|
| Allowed token audiencesの明確化 | App ServiceまたはFunctionsが受け入れるアクセストークンのaudを制限できる | APIのApplication ID URI、クライアントID、カスタムURIが正しく登録されているか |
| Issuer URLのv2.0化 | 旧形式のsts.windows.netではなく、Microsoft Entra IDの現在の推奨に沿った発行者URLへ寄せる | https://login.microsoftonline.com/<tenant-id>/v2.0形式になっているか |
| マネージドIDによるシークレットレス構成 | クライアントシークレットの期限切れや漏えいリスクを減らせる | ワークフォース構成でユーザー割り当てマネージドIDを使えるか |
| 追加チェックの活用 | クライアントアプリ、ID、テナント単位で受け入れ条件を絞れる | 「any application」を安易に許可していないか |
| 認証と認可の分離 | App Service認証だけでは細かな権限制御は完結しない | ロール、テナント、ユーザー属性の検証をアプリ側で実装しているか |
Allowed token audiencesが重要になった理由
Allowed token audiencesは、App ServiceまたはAzure Functionsが受け入れるアクセストークンを、audクレームの値で制限する設定です。公式ドキュメントでは、アプリ登録に紐づくトークンは既定で受け入れられますが、複数API、複数Application ID、カスタムApplication ID URIを使う場合は、追加のaudienceを明示する必要があると説明されています。設定済みのリストに一致しないaudを持つトークンは拒否されます。(Microsoft Learn)
これは、単なる設定項目の追加ではありません。APIを公開している企業では、「正しいユーザーがサインインしているか」だけでなく、「そのトークンがこのAPI向けに発行されたものか」を確認する必要があります。Allowed token audiencesは、その入口をApp Service認証側で狭めるための重要な制御点です。
Allowed token audiencesに入れる代表的な値
| 値の種類 | 例 | 使う場面 |
|---|---|---|
| Application client ID | アプリ登録のクライアントID | 既定のアプリ登録に対するトークンを受け入れる場合 |
| Application ID URI | api://<application-client-id> | SPA、ネイティブアプリ、別APIから対象APIを呼び出す場合 |
| カスタムApplication ID URI | https://contoso.com/api | 検証済みドメインを使ってAPIリソースを分かりやすく管理する場合 |
実務では、「何を入れれば動くか」ではなく、「どのリソース向けに発行されたトークンだけを受け入れるべきか」で判断します。たとえば社内ポータル用のApp Serviceに、別システム向けAPIのaudを追加すると、認証境界が曖昧になります。逆に、APIクライアントがapi://<client-id>をリソースとしてトークンを取得しているのに、Allowed token audiencesへその値を入れていないと、正規ユーザーでも401または403系のエラーになり得ます。
既存環境で確認すべき認証設定
Issuer URLはv2.0形式に寄せる
Microsoft公式ドキュメントでは、Issuer URLは<authentication-endpoint>/<tenant-id>/v2.0形式を使う説明になっています。グローバルAzureのワークフォーステナントでは、認証エンドポイントとしてhttps://login.microsoftonline.comを使う例が示されています。一方、クラウド環境によって認証エンドポイントは異なるため、米国政府クラウドや中国リージョンなどを扱うグローバル企業では、対象クラウドに合ったエンドポイントを確認する必要があります。 (Microsoft Learn)
特に注意したいのは、エクスプレス設定で作成したIDプロバイダーでは、Issuer URLが従来のhttps://sts.windows.netエンドポイントになる場合がある点です。公式ドキュメントでは、現在のMicrosoft Entra IDのベストプラクティスに合わせるため、https://login.microsoftonline.com/<tenant-id>/v2.0へ更新するよう案内されています。 (Microsoft Learn)
Client application、Identity、Tenantの追加チェックを使う
App Service認証では、追加チェックとしてクライアントアプリ、ID、テナントに関する要求を設定できます。Allowed token audiencesだけに頼るのではなく、どのアプリ、どのID、どのテナントからの要求を許可するかを組み合わせて設計するのが現実的です。(Microsoft Learn)
| 設定 | 目的 | 避けたい設定 |
|---|---|---|
| Client application requirement | 呼び出し元アプリを制限する | 理由なく「any application」を許可する |
| Identity requirement | 特定のユーザーまたはアプリIDに絞る | 退職者、廃止アプリ、古いサービスプリンシパルを残す |
| Tenant requirement | 同一テナントまたは許可テナントに絞る | マルチテナント構成でテナント検証をアプリ側に任せきりにする |
| Allowed token audiences | 対象API向けトークンだけを受け入れる | 動作確認のために不要なaudienceを追加する |
マルチテナントアプリでは、App Service認証を構成しただけで「どのテナントから来たか」を十分に制限できるとは考えない方が安全です。公式ドキュメントでも、マルチテナントシナリオではissuerとtenant IDを検証し、許可された値か確認する必要があると説明されています。(Microsoft Learn)
WebサイトとAPIで未認証時の応答を分ける
認証されていないリクエストへの応答は、WebサイトとAPIで適切な選択が異なります。公式ドキュメントでは、WebサイトにはHTTP 302リダイレクト、APIにはHTTP 401 Unauthorizedが推奨されています。(Microsoft Learn)
| 対象 | 推奨される応答 | 理由 |
|---|---|---|
| ブラウザーで使うWebアプリ | HTTP 302 Found redirect | 未ログインユーザーをサインイン画面へ誘導しやすい |
| REST API、Functions API | HTTP 401 Unauthorized | APIクライアントが認証失敗として処理しやすい |
| アクセス拒否を明確にしたい管理API | HTTP 403 Forbidden | 認証済みだが権限がないケースと整理しやすい |
| 存在を見せたくないエンドポイント | HTTP 404 Not found | セキュリティ要件に応じて利用するが、監査ログ設計が必要 |
APIで302リダイレクトを返す設定のままだと、クライアント側でHTMLのログインページを受け取ってしまい、原因調査が難しくなります。FunctionsをバックエンドAPIとして使う場合も、まず401を返す設計にするか確認しましょう。
シークレット運用からマネージドID利用への移行を検討する
2026年4月27日の差分では、マネージドIDを使った認証に関するプレビュー表記が削除されています。ただし、記事上のプレビュー表記が外れたことをもって、すべての組織で即時に本番導入できると短絡的に判断するのは危険です。利用するクラウド、テナント、変更管理、監査要件に合わせて検証する必要があります。(GitHub)
App ServiceのMicrosoft Entra認証では、クライアントシークレットの代わりにユーザー割り当てマネージドIDを使い、フェデレーションID資格情報を通じてクライアントアサーションとして利用する構成が説明されています。この方式は、クライアントシークレットの期限切れ対応や漏えいリスクを減らせる一方、公式ドキュメントではワークフォース構成で利用する方式として説明されています。(Microsoft Learn)
| 構成 | 向いている場面 | 注意点 |
|---|---|---|
| クライアントシークレット | 小規模環境、短期検証、既存運用を維持したい場合 | 期限切れ、ローテーション、漏えい対策が必要 |
| Key Vault参照 | シークレット管理を集中化したい場合 | App Serviceのアプリ設定、権限、スロット設定の整合性が必要 |
| ユーザー割り当てマネージドID | シークレットレス運用を進めたい本番環境 | フェデレーションID資格情報、対象テナント、IDの使い回し禁止を確認する |
マネージドIDを使う場合、ユーザー割り当てマネージドIDは対象のApp ServiceまたはAzure Functionsに限定して割り当てるべきです。公式ドキュメントでも、同じIDを別リソースに割り当てると、アプリ登録への不要なアクセスを与えることになると警告しています。(Microsoft Learn)
また、Microsoft Entraアプリやユーザー割り当てマネージドIDに追加できるフェデレーションID資格情報は最大20個です。複数環境や複数アプリで同じ設計を横展開する場合は、この上限も設計時に確認しておきましょう。(Microsoft Learn)
新規構成時はWorkforce tenantとExternal tenantを正しく選ぶ
Microsoft Entra認証の設定では、最初に「誰がサインインするアプリなのか」を決めます。公式ドキュメントでは、従業員やビジネスゲスト向けならワークフォーステナント、消費者やビジネス顧客向けなら外部テナントを使う説明になっています。(Microsoft Learn)
| 選択肢 | 主な利用者 | 典型例 |
|---|---|---|
| Workforce configuration | 従業員、社内ユーザー、B2Bゲスト | 社内ポータル、管理画面、業務API |
| External configuration | 消費者、外部顧客、B2C的なユーザー | 顧客向けWebサービス、会員サイト、外部ユーザー向け申請システム |
ワークフォース構成では、現在のテナントにアプリ登録を作成するケースが多くなります。一方、外部構成では既存の外部テナントを使うか、新しく作成してユーザーフローを構成します。外部テナントでは、メールとパスワード、メールのワンタイムパスコードなどのサインイン方法を扱い、必要に応じてGoogleやFacebookをIDプロバイダーとして追加できます。(Microsoft Learn)
アプリ登録は「自動作成」でよいとは限らない
App Service認証では、アプリ登録を自動作成することも、既存のアプリ登録を指定することもできます。公式ドキュメントでは、特別な理由がなければ新しいアプリ登録を自動作成し、必要に応じてMicrosoft Entra管理センターで後からカスタマイズできると説明されています。一方で、アプリ登録を作成する権限がない場合、App Serviceと異なるテナントのアプリ登録を使う場合、政府クラウドで自動作成オプションが利用できない場合などは、既存登録を使う判断になります。(Microsoft Learn)
セキュリティや監査の観点では、アプリ登録の共有を避けることが重要です。公式ドキュメントでも、各App Serviceアプリに専用のアプリ登録を構成し、権限と同意をアプリごとに分け、環境間で権限を共有しないことがベストプラクティスとして示されています。(Microsoft Learn)
| 判断 | 向いているケース | 管理上の注意 |
|---|---|---|
| 新規アプリ登録を自動作成 | 同一テナント内の標準的なWebアプリ | Issuer URL、サポートされるアカウント種別、Graph権限を後で確認する |
| 既存アプリ登録を指定 | IDチームが登録を集中管理している環境 | リダイレクトURI、シークレット、API公開、スコープを手動で整える |
| テナント外のアプリ登録を指定 | 外部テナントやマルチテナント構成 | tenant ID、issuer、audience、同意フローを慎重に確認する |
認証と認可を混同しない
App Serviceの組み込み認証は、リクエスト元が「誰か」を確認する仕組みです。一方で、「そのユーザーやアプリが何をしてよいか」を判断する認可は、App Service認証だけで完結しない場合があります。公式ドキュメントでも、既定ではApp Service認証は主に認証を扱い、認可はアプリケーションコード側で判断する必要があると説明されています。(Microsoft Learn)
たとえば、管理者画面を保護する場合に「Microsoft Entraでログインできた人は全員管理者」としてしまうのは危険です。アプリ側では、x-ms-client-principalヘッダーやアクセストークンのクレームを使い、ユーザーのグループ、ロール、テナントID、アプリロールなどを検証する必要があります。公式ドキュメントでは、x-ms-client-principalヘッダーにはBase64エンコードされたJSON形式のクレーム情報が含まれ、必要に応じてx-ms-token-aad-access-tokenから基礎となるアクセストークンも扱えると説明されています。(Microsoft Learn)
サービス間通信でも同じです。デーモンクライアントがクライアント資格情報フローでApp Service APIを呼び出す場合、トークンにrolesクレームが含まれることがありますが、App Service認証はそのロール検証を自動では行いません。対象App ServiceまたはFunctions側のコードで、期待するロールを検証する必要があります。(Microsoft Learn)
Microsoft Graph移行もあわせて確認する
古いアプリでは、Azure AD Graphに依存した認可ロジックやグループ確認が残っていることがあります。Microsoft公式ドキュメントでは、Azure AD Graphは非推奨であり、Microsoft Graphへ移行する必要があると説明されています。移行時には、App Service認証設定からhttps://graph.windows.netへの参照やAzure AD Graph向けスコープを外し、Microsoft Graph権限に合わせた設定へ更新します。(Microsoft Learn)
特に2026年時点で既存環境を見直すなら、次の設定を確認してください。
| 確認項目 | 見る場所 | 対応 |
|---|---|---|
| Azure AD Graphの参照 | App Service認証設定、アプリ登録、コード | graph.windows.netを使っていないか確認する |
| Issuer URL | Microsoft IDプロバイダー設定 | /v2.0付きのIssuer URLへ寄せる |
| Microsoft Graph権限 | アプリ登録のAPI permissions | 必要最小限のMicrosoft Graph権限だけを付与する |
| サインインパラメーター | authsettingsまたはauthsettingsV2 | Microsoft Graphの.defaultスコープ利用を検討する |
| アプリコード | グループ、ユーザー、ロール取得処理 | Microsoft Graph SDKまたはAPIに置き換える |
security admins、identity teams、compliance teamsの確認観点
2026年4月更新は、Azure管理者だけでなく、ID管理、監査、コンプライアンス担当にも影響します。チームごとに見るべき観点を分けると、確認漏れを減らせます。
| 担当チーム | 優先して確認すること | 判断基準 |
|---|---|---|
| security admins | Allowed token audiences、未認証時応答、追加チェック | 不要なaudienceや「any application」を許可していないか |
| identity teams | アプリ登録、Issuer URL、テナント種別、Graph権限 | テナント、スコープ、同意が設計通りか |
| compliance teams | シークレット管理、監査証跡、環境分離 | 本番・検証・開発でアプリ登録や権限を共有していないか |
| 開発チーム | クレーム検証、ロール検証、APIの401処理 | 認可ロジックをApp Service認証任せにしていないか |
| SRE・運用チーム | トークンストア、ログ、障害時の切り分け | 401、403、リダイレクトループを調査できるログがあるか |
更新後に失敗しやすいポイント
| 症状 | よくある原因 | 対処 |
|---|---|---|
| 正しいユーザーなのにAPIが拒否される | トークンのaudがAllowed token audiencesに含まれていない | 実際のアクセストークンのaudを確認し、必要な値だけを追加する |
| APIクライアントがHTMLログイン画面を受け取る | 未認証時応答が302リダイレクトになっている | APIでは401 Unauthorizedを選ぶ |
| 一部のクライアントアプリだけ失敗する | Client application requirementで許可されていない | 呼び出し元アプリのclient IDを棚卸しする |
| 別テナントからのアクセスが想定外に通る | マルチテナント構成でtenant ID検証が弱い | 許可テナントを明示し、アプリコードでも検証する |
| ある日突然サインインできなくなる | クライアントシークレットの期限切れ | Key Vault参照またはマネージドID利用を検討する |
| ロールを付けたのに権限制御されない | App Service認証がロール検証を自動実行すると誤解している | アプリ側でrolesクレームを検証する |
| Microsoft Graph権限変更後にエラーが出る | Azure AD Graph向け設定が残っている | graph.windows.net参照と古いスコープを削除する |
既存App Serviceで今すぐ行うべき確認手順
- Azure Portalで対象のApp ServiceまたはAzure Functionsを開き、Settings > Authenticationを確認する。
- Microsoft IDプロバイダーの設定を開き、アプリ登録、Issuer URL、Client secret setting name、Allowed token audiencesを記録する。
- Issuer URLが
https://login.microsoftonline.com/<tenant-id>/v2.0形式になっているか確認する。国家クラウドや特殊リージョンでは、対象クラウドに合う認証エンドポイントを使う。 - APIとして公開しているアプリでは、実際にクライアントが取得しているアクセストークンの
audを確認し、Allowed token audiencesに必要最小限の値だけを登録する。 - Client application requirement、Identity requirement、Tenant requirementを確認し、不要な「any application」や過剰に広いテナント許可を削る。
- Webサイトは302、APIは401を基本に、未認証リクエストへの応答を見直す。
- クライアントシークレットを使っている場合は、期限、ローテーション手順、Key Vault参照、マネージドIDへの移行可否を確認する。
- アプリコードで、tenant ID、issuer、roles、groups、appidまたはazpなど、認可に必要なクレームを検証しているか確認する。
- Azure AD Graphへの参照が残っていないか、アプリ登録、App Service認証設定、コード、設定ファイルを横断して確認する。
- 最後に、設定変更前後の値、テスト結果、承認者、影響範囲を記録し、監査証跡として残す。
次に取るべき対応
Azure App ServiceのMicrosoft Entra Authenticationをすでに使っている場合、まずはAllowed token audiencesとIssuer URLを確認してください。APIを公開している環境では、audクレームの不一致が認証エラーの原因になるだけでなく、逆に広く許可しすぎると不要なトークンまで受け入れるリスクがあります。
次に、クライアントシークレットを使い続けるのか、Key Vault参照やマネージドIDを使うのかを決めます。シークレットレス化は運用負荷と漏えいリスクを下げられますが、フェデレーションID資格情報、テナント、IDの割り当て範囲を正しく設計する必要があります。
最後に、App Service認証を「ログインできるかどうか」だけで評価しないことが重要です。認証の入口はApp Serviceに任せつつ、認可はアプリコード、テナント制御、ロール検証、監査ログまで含めて設計することで、2026年4月更新の意図に沿った安全な構成に近づけます。
コメント