Azure App ServiceのWebアプリに認証を追加するなら、まず確認すべきポイントは「App Service認証を有効にするだけで十分か」「Microsoft Entraのどのテナントを使うか」「未認証アクセスをどう扱うか」の3つです。公式クイックスタートでは、Azure App Service上のWebアプリに組み込み認証を追加し、Microsoft EntraをIDプロバイダーとして使って、組織内ユーザーにアクセスを制限する手順が示されています。(Microsoft Learn)
特に管理者や開発者が注意すべきなのは、この手順が「ログイン画面を付ける方法」だけではない点です。アプリ登録、テナント種別、クライアントシークレット、有効なトークンの対象、未認証リクエスト時の応答、検証方法まで含めて確認しないと、意図せず外部ユーザーが入れる構成になったり、APIで302リダイレクトが返ってクライアント処理が壊れたりする可能性があります。
なお、Microsoft Learnの該当ページでは、確認時点で日本語版は2026年4月13日、英語版は2026年4月17日の最終更新と表示されています。2026年5月20日時点の公式情報として社内展開や記事化を行う場合も、実際の運用判断では公式ページの更新日と現在のAzureポータル表示をあわせて確認してください。(Microsoft Learn)
Azure App Serviceのアプリ認証クイックスタートで整理された内容
今回のクイックスタートは、Azure App Serviceで動作するWebアプリに対して、App Serviceの組み込み認証・承認機能を使い、Microsoft Entraによるサインインを設定する内容です。
App Service認証は、アプリケーションコードの前段で動作する認証モジュールです。有効化すると、受信したHTTPリクエストはアプリコードで処理される前に認証・承認モジュールを通過します。Microsoft Learnでは、SDK、特定言語、アプリケーションコードの変更なしに構成できる機能として説明されています。(Microsoft Learn)
実務上は、次のような用途に向いています。
| 利用シーン | App Service認証が向いている理由 | 注意点 |
|---|---|---|
| 社内向けポータル | Microsoft Entraの組織ユーザーだけにアクセスを限定しやすい | 退職者・異動者のアクセス制御はEntra側の運用も必要 |
| 開発・検証環境の保護 | アプリ改修なしで認証を追加できる | 本番と同じアプリ登録を使い回さない |
| 簡易な業務Webアプリ | ログイン機能を自前実装せずに導入できる | ロール別権限など細かな認可はアプリ側実装が必要 |
| APIを含むアプリ | 未認証アクセスをブロックできる | Webサイト向けの302ではなく、APIでは401を検討する |
ポイントは、App Service認証が「認証を簡単に追加する仕組み」であり、すべての認可要件を自動で満たすものではないことです。Microsoft Learnでも、既定では認証を主に扱い、リソースへのアクセス可否などの認可判断はアプリケーション側で必要になる場合があると説明されています。(Microsoft Learn)
何が変わるのか：実務上の注目ポイント
今回の公式クイックスタートを読むうえで重要なのは、「Azure App Serviceに破壊的変更が入る」というより、現在の推奨手順に沿って認証設定をどう確認すべきかが明確になっている点です。
特に注目すべきポイントは次の4つです。
| 注目点 | 内容 | 影響を受けやすい担当者 |
|---|---|---|
| Microsoft Entraを前提にした手順 | IDプロバイダーとしてMicrosoftを選択し、Microsoft Entraの組織ユーザーに制限する | Azure管理者、ID管理者 |
| テナント種別の選択 | 従業員・ビジネスゲスト向けのWorkforce構成と、外部ユーザー向けのExternal構成が分かれる | 情シス、SaaS開発者 |
| アプリ登録の自動作成 | App Service認証設定時にMicrosoft Entra側のアプリ登録を作成する手順が含まれる | Entra管理者、開発者 |
| 未認証リクエストの扱い | WebサイトではHTTP 302、APIではHTTP 401など、用途に応じた選択が必要 | Web開発者、API開発者 |
クイックスタートでは、従業員やビジネスゲスト向けには「Workforce configuration」、外部ユーザー向けには「External configuration」を使う流れが示されています。社内利用なのに外部構成を選ぶ、または外部顧客向けなのに現在の組織テナントだけに制限する、といった設定ミスは運用後の手戻りにつながります。(Microsoft Learn)
対象者：誰が確認すべきか
この公式情報は、Azure App Serviceを直接操作する開発者だけでなく、Microsoft Entra、セキュリティ、運用管理に関わる担当者も確認すべき内容です。
Azure管理者が確認すべきこと
Azure管理者は、対象のApp Serviceで認証が有効になっているか、どのIDプロバイダーが設定されているかを確認します。
特に確認したい項目は以下です。
| 確認項目 | 推奨される確認内容 |
|---|---|
| Authentication設定 | 「Require authentication」になっているか |
| IDプロバイダー | Microsoft Entraが意図したテナントで構成されているか |
| 未認証リクエスト | Webアプリなら302、APIなら401など用途に合っているか |
| Token store | アプリがユーザートークンを利用する場合に有効か |
| デプロイスロット | 本番・検証で別のアプリ登録を使っているか |
App Service認証はポータルから簡単に有効化できますが、簡単であるほど「誰が、どのテナントで、どの権限を持つアプリ登録を作ったか」が見落とされがちです。運用環境では、作業履歴と構成値をチケットや設計書に残しておくことをおすすめします。
開発者が確認すべきこと
開発者は、App Service認証を有効にした後のアプリ動作を確認する必要があります。
たとえば、ログイン後のユーザー情報をアプリ内で使う場合、App Service認証が渡すヘッダーやトークンをどう扱うかを決めます。さらに、管理者だけが見られる画面、一般ユーザーも見られる画面といったロール制御が必要な場合は、App Service認証だけで完結すると考えないほうが安全です。
App Service認証で「ユーザーが誰か」を確認し、アプリ側で「そのユーザーに何を許可するか」を判断する、という分担で設計すると失敗しにくくなります。
Microsoft Entra管理者が確認すべきこと
Microsoft Entra管理者は、アプリ登録、サポートされているアカウントの種類、シークレット、APIアクセス許可を確認します。
クイックスタートでは、組織内ユーザーだけに制限する場合、アプリ登録のサポートされるアカウント種別を「現在のテナント・単一テナント」にする手順が示されています。また、クライアントシークレットの有効期限として推奨180日を選ぶ手順も含まれています。(Microsoft Learn)
180日後に突然ログインできなくなる、といった障害を避けるには、シークレットの期限を監視対象に入れるか、可能な範囲でマネージドIDを使う構成を検討します。Microsoft Learnでは、App Service認証をクライアントシークレットではなくIDで構成する方法にも触れています。(Microsoft Learn)
基本構成：社内向けWebアプリに認証を追加する流れ
社内向けWebアプリであれば、基本的な流れは次のようになります。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | App ServiceにWebアプリを用意する | アプリ名とリソースグループ名を控える |
| 2 | App Serviceの「認証」からIDプロバイダーを追加する | Microsoftを選択する |
| 3 | テナント種別を選ぶ | 社内向けはWorkforce configurationを選ぶ |
| 4 | アプリ登録を作成する | 表示名、アカウント種別、シークレット期限を確認する |
| 5 | 追加チェックを設定する | クライアント、ID、テナント要件を確認する |
| 6 | 認証設定を有効化する | Require authenticationにする |
| 7 | アクセス確認を行う | 組織内ユーザーと外部アカウントでテストする |
公式クイックスタートでは、App Serviceの左メニューから「認証」を選び、「IDプロバイダーの追加」を行い、MicrosoftをIDプロバイダーとして選ぶ手順が示されています。その後、現在のテナントを使うWorkforce構成を選び、新しいアプリ登録を作成する流れです。(Microsoft Learn)
「現在のテナント・単一テナント」を選ぶ意味
社内向けWebアプリでは、サポートされるアカウントの種類を「現在のテナント・単一テナント」にするのが基本です。これにより、その組織のMicrosoft Entraテナント内のユーザーを対象にできます。
ただし、「単一テナントにすれば絶対に全アクセス制御が完了する」という意味ではありません。ゲストユーザーを招待している場合、そのゲストが対象になる可能性があります。特定部署だけに限定したい場合や、管理者ロールだけを許可したい場合は、Entra側のユーザー割り当て、グループ、アプリロール、またはアプリケーションコード側の認可処理も検討します。
未認証リクエストはWebサイトとAPIで分ける
未認証リクエストに対する応答は、実務でよくミスが起きる箇所です。
公式ドキュメントでは、WebサイトではHTTP 302リダイレクト、APIではHTTP 401 Unauthorizedが推奨される選択肢として示されています。(Microsoft Learn)
| 用途 | 選びやすい設定 | 理由 |
|---|---|---|
| ブラウザで使う社内Webサイト | HTTP 302 Found redirect | 未ログイン時にサインイン画面へ誘導しやすい |
| REST API | HTTP 401 Unauthorized | APIクライアントが認証エラーとして処理しやすい |
| 存在を隠したい管理API | HTTP 404 Not foundを検討 | ただし監査・運用設計と合わせて判断する |
| 明確に拒否したい管理画面 | HTTP 403 Forbiddenを検討 | 認証済みだが権限不足の扱いと混同しないよう注意 |
WebアプリとAPIを同じApp Serviceで動かしている場合は、302がAPIクライアントに返ってしまい、JSONを期待する処理がHTMLのログイン画面を受け取ることがあります。API利用がある場合は、エンドポイント構成を分けるか、認証設定とアプリ側処理の役割を事前に整理してください。
外部ユーザー向け構成で注意すべきこと
外部顧客や一般ユーザーにサインインさせる場合は、社内向けのWorkforce構成ではなく、External configurationを使う流れが示されています。外部構成では、既存の外部テナントを選ぶか、新しい外部テナントを作成し、ユーザーフローやブランド設定を行う手順が含まれます。(Microsoft Learn)
外部ユーザー向けで特に注意したいのは、次の点です。
| 注意点 | 具体例 | 対応策 |
|---|---|---|
| サインアップ可否 | 誰でもメールアドレスで登録できる状態になる | ユーザーフローとアクセス条件を確認する |
| ブランド上書き | 既存テナントのブランド設定を変更してしまう | 変更前に影響範囲を確認する |
| テナント管理 | 検証用外部テナントが残り続ける | 不要になったら削除手順を実施する |
| 顧客データ保護 | 外部ユーザーの属性・同意管理が必要 | プライバシー・規約・監査要件を整理する |
外部ユーザー向けの認証は、社内SSOよりも運用設計の影響が大きくなります。ユーザー登録、退会、パスワードリセット、サポート窓口、監査ログ確認まで含めて設計してください。
既存環境への影響範囲
今回のクイックスタートを確認して、既存環境で特に棚卸しすべき範囲は次のとおりです。
既存のApp Service認証設定
まず、対象App Serviceの「認証」設定を確認します。古い手順で構成したアプリでは、未認証リクエスト時の動作、トークンストア、アプリ登録、シークレット期限が現在の運用ルールと合っていないことがあります。
確認すべき項目は以下です。
| 項目 | 確認内容 |
|---|---|
| 認証の有効化 | 本当に認証が必須になっているか |
| IDプロバイダー | Microsoft Entraの正しいテナントを参照しているか |
| 発行者URL | 単一テナント・マルチテナントの意図と一致しているか |
| Allowed token audiences | 想定するaud値だけが許可されているか |
| Token store | アプリが必要とする場合だけ有効か |
| クライアントシークレット | 期限切れ・期限間近ではないか |
Allowed token audiencesは、受け入れるアクセストークンのaudクレームを制限する設定です。複数のクライアントアプリやカスタムApplication ID URIを使っている場合、明示的な設定が必要になることがあります。設定されている場合、許可リストに一致しないaudのトークンは拒否されます。(Microsoft Learn)
Microsoft Entraのアプリ登録
App Service認証をポータルから設定すると、Microsoft Entra側にアプリ登録が作成されます。ここで問題になりやすいのが、環境間の使い回しです。
Microsoft Learnでは、各App Serviceアプリに個別のアプリ登録を構成し、権限と同意を分け、本番・検証などの環境間で権限を共有しないことがベストプラクティスとして示されています。(Microsoft Learn)
たとえば、検証スロットと本番スロットで同じアプリ登録を使っていると、検証用に追加したリダイレクトURIや権限が本番にも影響する可能性があります。安全に運用するなら、少なくとも本番、ステージング、開発でアプリ登録を分ける設計にしてください。
Azure AD Graphを使っていた古い実装
古いアプリでは、Azure AD Graphに依存している場合があります。Microsoft Learnでは、Azure AD GraphからMicrosoft Graphへの移行が必要であり、App Service認証の構成変更が必要になる場合があると説明されています。(Microsoft Learn)
特に、https://graph.windows.netへの参照、古いresourceパラメーター、Azure AD Graph向けの権限要求が残っていないかを確認してください。アプリコード内でグループメンバーシップ確認やユーザー属性取得を行っている場合は、Microsoft Graphへの移行計画もあわせて立てる必要があります。
管理者・開発者向けチェックリスト
公開前、または既存環境の棚卸し時には、次のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 管理者 | 開発者 | 確認のポイント |
|---|---|---|---|
| 対象App Serviceを特定した | ○ | ○ | アプリ名、リソースグループ、サブスクリプションを確認 |
| 認証が必須になっている | ○ | 「Require authentication」か | |
| IDプロバイダーが正しい | ○ | Microsoft Entraの意図したテナントか | |
| アカウント種別が適切 | ○ | 社内向けなら単一テナントを基本に検討 | |
| 未認証時の応答が適切 | ○ | ○ | Webは302、APIは401を基本に検討 |
| Token storeの要否を判断した | ○ | Microsoft Graphなどのトークン利用があるか | |
| アプリ登録を環境ごとに分けた | ○ | ○ | 本番と検証で使い回していないか |
| クライアントシークレット期限を管理している | ○ | 期限切れ前の更新手順があるか | |
| 外部アカウントで侵入テストをした | ○ | ○ | 個人Microsoftアカウントや別テナントで確認 |
| アプリ側の認可処理を確認した | ○ | ロール、グループ、部署制御が必要か |
このチェックリストで重要なのは、Azureポータルの設定だけを見て終わらせないことです。実際に未ログイン状態、組織内ユーザー、権限のないユーザー、外部アカウントでアクセスし、期待通りの挙動になるかを確認してください。
展開時に失敗しやすいポイント
302リダイレクトをAPIに返してしまう
最もよくある失敗の一つが、APIに対して302リダイレクトを返してしまうことです。
ブラウザで見るWebサイトなら、未ログイン時にサインイン画面へリダイレクトされるのは自然です。しかしAPIクライアントやバッチ処理では、302を認証エラーとして扱えない場合があります。その結果、HTMLのログイン画面をAPIレスポンスとして受け取り、JSONパースエラーが発生することがあります。
APIを守る場合は、HTTP 401 Unauthorizedを基本に検討してください。(Microsoft Learn)
「認証」と「認可」を混同する
App Service認証を有効にすると、ログインしていないユーザーをブロックできます。しかし、ログインしたユーザー全員に同じ操作を許可してよいとは限りません。
たとえば、社内ポータルで次のような要件がある場合は、アプリ側の認可処理が必要です。
- 人事部だけが従業員情報を閲覧できる
- 管理者だけがマスターデータを更新できる
- 営業担当者は自分の顧客だけを閲覧できる
- ゲストユーザーは一部画面に入れない
App Service認証は、ユーザーやクレーム情報をアプリ側へ渡せます。そこから先の業務権限制御は、アプリケーション側で実装・検証するのが基本です。
クライアントシークレットの期限切れを見落とす
クイックスタートでは、クライアントシークレットの有効期限として推奨180日を選ぶ手順が示されています。(Microsoft Learn)
これはセキュリティ上は望ましい一方、運用上は期限切れによる障害の原因になります。特に、作成者が退職した、検証時に作った設定を本番で使い続けている、更新手順がない、といった環境では注意が必要です。
対応策としては、以下を検討してください。
| 対応策 | 内容 |
|---|---|
| 期限を台帳化する | アプリ登録名、シークレット名、期限、担当者を記録する |
| 監視・通知する | 期限前に更新作業が発生するよう運用に組み込む |
| 更新手順を作る | シークレット更新後のApp Service設定変更と動作確認を明文化する |
| マネージドIDを検討する | シークレット管理を減らせる構成が適用できるか確認する |
外部テナントを作ったまま放置する
外部構成を試すと、外部テナント、ユーザーフロー、アプリ登録などが作成される場合があります。公式クイックスタートでも、不要になったリソース、アプリ登録、外部テナントは削除するよう説明されています。(Microsoft Learn)
検証後に放置すると、課金だけでなく、使われていないID基盤が残るリスクもあります。検証用に作ったものは、作成時点で削除予定日と担当者を決めておくと管理しやすくなります。
移行・見直し時の進め方
既存のApp Serviceに認証を追加する、または古い認証設定を見直す場合は、いきなり本番に反映しないでください。おすすめの進め方は次の通りです。
| フェーズ | 作業内容 | 成果物 |
|---|---|---|
| 現状確認 | App Service認証、Entraアプリ登録、シークレット、API利用状況を確認 | 構成一覧 |
| 方針決定 | 社内向けか外部向けか、WebかAPIかを整理 | 認証・認可方針 |
| 検証 | ステージング環境でApp Service認証を有効化 | 動作確認結果 |
| 移行 | 本番に設定を反映 | 変更作業記録 |
| 運用 | シークレット期限、アプリ登録、アクセス権を定期確認 | 運用チェックリスト |
特に、既存アプリでログイン機能を自前実装している場合は、App Service認証との二重認証にならないかを確認してください。ログイン後のセッション、ログアウト処理、リダイレクトURI、Cookie、CSRF対策などが影響を受ける可能性があります。
本番反映前の動作確認
設定後は、Microsoft Entra管理センターでアプリ登録を確認し、サポートされるアカウント種別が意図通りかを見ます。公式クイックスタートでも、作成されたアプリ登録の「Supported account types」が「My organization only」になっているかを確認し、組織外ユーザーのサインインが失敗または拒否されることを検証する手順が示されています。(Microsoft Learn)
本番反映前には、少なくとも次のテストを行ってください。
| テスト | 期待結果 |
|---|---|
| 未ログインでアクセス | サインイン画面へ誘導、または401が返る |
| 組織内ユーザーでアクセス | 正常にWebアプリを利用できる |
| 権限のない組織内ユーザーでアクセス | アプリ側の認可で拒否される |
| 個人Microsoftアカウントでアクセス | 社内向けアプリでは拒否される |
| 別テナントの職場アカウントでアクセス | 単一テナント構成では拒否される |
| APIクライアントからアクセス | 期待するステータスコードとレスポンスが返る |
| シークレット更新後のアクセス | サインインが継続して成功する |
テストは通常ブラウザだけでなく、シークレットウィンドウ、別ユーザー、APIクライアントでも行います。ブラウザの既存セッションが残っていると、設定ミスに気づけないことがあります。
まとめ：まず確認すべき次のアクション
Azure App Serviceの「Quickstart: Add app authentication to your web app running on Azure App Service」は、WebアプリにMicrosoft Entra認証を追加し、組織内ユーザーにアクセスを制限するための基本手順です。重要なのは、ポータルで認証を有効化するだけでなく、テナント種別、アプリ登録、未認証時の応答、トークン、認可処理、クリーンアップまで含めて確認することです。
これから対応する場合は、まず対象のApp Serviceを一覧化し、次の3点を確認してください。
- 社内向けか、外部ユーザー向けか
- Webサイトか、APIか、両方か
- App Service認証だけで足りるか、アプリ側の認可処理が必要か
そのうえで、検証環境でApp Service認証を有効化し、組織内ユーザー、外部アカウント、未認証アクセス、APIアクセスを実際にテストします。認証は「設定できた」だけでは不十分です。誰が入れて、誰が入れないのかを確認できて初めて、本番運用に載せられます。
コメント