Azure App Service および Azure Functions での認証と承認

2025-04-17

Azure App Service には、組み込みの認証 (ユーザーのサインイン) と承認 (セキュリティで保護されたデータへのアクセスを提供する) 機能が用意されています。これらの機能は、 Easy Auth と呼ばれることもあります。Web アプリ、RESTful API、モバイルサーバー、および関数でコードをほとんどまたはまったく記述せず、ユーザーのサインインやデータへのアクセスに使用できます。

この記事では、App Service によりアプリの認証と認可を簡略化する方法について説明します。

組み込み認証を使用する理由

認証と承認を実装するには、選択した Web フレームワークにバンドルされたセキュリティ機能を使用するか、独自のツールを記述できます。認証と承認のためのセキュリティで保護されたソリューションの実装には、多大な労力が必要な場合があります。業界のベストプラクティスと標準に従う必要があります。また、最新のセキュリティ、プロトコル、ブラウザーの更新プログラムを使用して、ソリューションを最新の状態に保つ必要もあります。

App Service と Azure Functions の組み込み機能は、フェデレーション ID プロバイダーですぐに使用できる認証を提供することで、時間と労力を節約できるため、アプリケーションの残りの部分に集中できます。

App Service を使用すると、認証機能を自分で実装しなくても、Web アプリまたは API に統合できます。この機能はプラットフォームに直接組み込まれており、特定の言語、SDK、セキュリティの専門知識、またはコードは必要ありません。 Microsoft Entra、Facebook、Google、X などの複数のサインインプロバイダーと統合できます。

アプリでは、Visual Studio の統合や増分同意など、より複雑なシナリオをサポートする必要がある場合があります。これらのシナリオをサポートするために、いくつかの認証ソリューションを使用できます。詳細については、認証のシナリオと推奨事項に関するページを参照してください。

ID プロバイダー

App Service はフェデレーション ID を使用します。 Microsoft または Microsoft 以外の ID プロバイダーが、ユーザー ID と認証フローを自動的に管理します。次の ID プロバイダーを既定で利用できます。

プロバイダー	サインインエンドポイント	使用方法に関するガイダンス
Microsoft Entra	`/.auth/login/aad`	App Service Microsoft Entra プラットフォームのサインイン
フェイスブック	`/.auth/login/facebook`	App Service Facebook サインイン
グーグル	`/.auth/login/google`	App Service Google サインイン
X	`/.auth/login/x`	App Service X サインイン
GitHubの	`/.auth/login/github`	App Service GitHub サインイン
林檎	`/.auth/login/apple`	Apple による App Service サインイン (プレビュー)
任意の OpenID Connect プロバイダー	`/.auth/login/<providerName>`	App Service OpenID Connect サインイン

これらのプロバイダーのいずれかでこの機能を構成すると、そのプロバイダーのサインインエンドポイントが、ユーザー認証と、プロバイダーからの認証トークンの検証に使用できるようになります。任意の数のサインインオプションを、ユーザーに対して提供できます。

組み込みの認証の使用に関する考慮事項

組み込み認証を有効にすると、App Service の構成設定に関係なく、アプリケーションへのすべての要求が HTTPS に自動的にリダイレクトされます。この自動リダイレクトは、V2 構成の requireHttps 設定を使用して無効にすることができます。ただし、HTTPS を引き続き使用し、セキュリティで保護されていない HTTP 接続を介してセキュリティトークンが送信されないようにすることをお勧めします。

App Service を使用して、サイトのコンテンツと API へのアクセスを制限するかどうかにかかわらず、認証を行うことができます。 Web アプリの >>] セクションでアクセス制限を設定します。

認証されたユーザーのみにアプリアクセスを制限するには、構成された ID プロバイダーのいずれかでサインイン するように要求が認証されていない場合に実行するアクション を設定します。
認証してもアクセスを制限しない場合 は、要求が認証されていないときに実行するアクションを[匿名要求を許可する (アクションなし)] に設定します。

重要

各アプリの登録には、独自のアクセス許可と同意が割り当てられるようにしてください。デプロイスロットごとに個別のアプリ登録を使用することで、環境間でアクセス許可を共有することを回避します。新しいコードをテストする場合、この方法は、問題が運用アプリに影響するのを防ぐのに役立ちます。

しくみ

機能のアーキテクチャ

認証および承認ミドルウェアコンポーネントは、アプリケーションと同じ仮想マシン上で実行されるプラットフォームの機能です。これを有効にすると、アプリケーションで処理される前に、すべての受信 HTTP 要求がそのコンポーネントを通過します。

プラットフォームミドルウェアは、アプリに対していくつかの処理を行います。

指定された ID プロバイダーを使用してユーザーとクライアントを認証する
構成された ID プロバイダーが発行した OAuth トークンを検証、格納、および更新します
認証されたセッションを管理します
HTTP 要求ヘッダーに ID 情報を挿入する

モジュールは、アプリケーションコードとは別に実行されます。構成するには、Azure Resource Manager の設定を使用するか、構成ファイルを使用します。 SDK、特定のプログラミング言語、またはアプリケーションコードの変更は必要ありません。

Windows の機能のアーキテクチャ (コンテナー以外のデプロイ)

認証と認可のモジュールは、アプリケーションと同じサンドボックスでネイティブの IIS モジュールとして実行されます。これを有効にすると、アプリケーションが処理する前に、すべての受信 HTTP 要求がそれを通過します。

Linux およびコンテナーの機能のアーキテクチャ

認証と承認モジュールは、アプリケーションコードから分離された別のコンテナーで実行されます。このモジュールでは、アンバサダーパターンを使用して受信トラフィックと対話し、Windows と同様の機能を実行します。プロセスでは実行されないため、特定の言語フレームワークとの直接統合は不可能です。ただし、アプリに必要な関連情報は、要求ヘッダーで渡されます。

認証フロー

認証フローはすべてのプロバイダーで同じです。プロバイダーの SDK を使用してサインインするかどうかによって異なります。

プロバイダー SDK がない場合: アプリケーションは、フェデレーションサインインを App Service に委任します。通常、この委任は、プロバイダーのサインインページをユーザーに表示できるブラウザーアプリの場合です。サーバーコードはサインインプロセスを管理するため、 サーバー向けフロー または サーバーフローとも呼ばれます。

このケースは、認証に埋め込みブラウザーが使用されるブラウザーアプリとモバイルアプリに適用されます。
プロバイダー SDK の場合: アプリケーションはユーザーをプロバイダーに手動でサインインします。次に、検証のために認証トークンを App Service に送信します。通常、このプロセスは、プロバイダーのサインインページをユーザーに表示できないブラウザーレスアプリの場合です。アプリケーションコードはサインインプロセスを管理するため、 クライアント向けフロー または クライアントフローとも呼ばれます。

このケースは、サインインプロセスの柔軟性を高める必要があるブラウザーアプリに加えて、REST API、 Azure Functions、JavaScript ブラウザークライアントにも適用されます。また、プロバイダーの SDK を使用してユーザーをサインインさせるネイティブモバイルアプリにも適用されます。

App Service の信頼されたブラウザーアプリから App Service または Azure Functions の別の REST API への呼び出しは、サーバー向けフローを通じて認証できます。詳細については、Azure App Service 認証でのサインインとサインアウトのカスタマイズに関する記事をご覧ください。

次の表は認証フローの手順をまとめたものです。

手順	プロバイダーの SDK を使わない場合	プロバイダーの SDK を使う場合
1. ユーザーをサインインする	プロバイダーは、クライアントを `/.auth/login/<provider>`にリダイレクトします。	クライアントコードは、プロバイダーの SDK を使用してユーザーを直接サインインさせ、認証トークンを受け取ります。詳細については、プロバイダーのドキュメントを参照してください。
2.認証後処理を実施する	プロバイダーは、クライアントを `/.auth/login/<provider>/callback`にリダイレクトします。	クライアントコードは、検証のためにプロバイダーからトークンを`/.auth/login/<provider>`に投稿します。
3. 認証済みセッションを確立する	App Service によって、認証された Cookie が応答に追加されます。	App Service は、独自の認証トークンをクライアントコードに返します。
4.認証済みのコンテンツを提供する	クライアントは、後続の要求に認証 Cookie を含めます (ブラウザーによって自動的に処理されます)。	クライアントコードは、 `X-ZUMO-AUTH` ヘッダーに認証トークンを提示します。

クライアントブラウザーの場合、App Service は認証されていないすべてのユーザーを /.auth/login/<provider> に自動的に送ることができます。また、任意のプロバイダーを使用して、アプリにサインインするための 1 つ以上の /.auth/login/<provider> リンクをユーザーに提示することもできます。

認可の挙動

Azure portal では、受信要求が認証されていない場合のさまざまな動作で App Service を構成できます。以降のセクションでは、オプションについて説明します。

重要

既定では、この機能は認証のみを提供し、承認は提供しません。ここで構成するチェックに加えて、アプリケーションで承認の決定を行う必要がある場合があります。

制限付きアクセス

認証されていない要求を許可する: このオプションは、認証されていないトラフィックの承認をアプリケーションコードに延期します。認証された要求について、App Service は HTTP ヘッダーで認証情報も渡します。

このオプションでは、匿名要求をいっそう柔軟に処理できます。たとえば、ユーザーに複数のサインインプロバイダーを提示することができます。ただし、コードを記述する必要があります。
認証が必要: このオプションでは、認証されていないとき、アプリケーションへのトラフィックを拒否します。実行する具体的なアクションについては、この記事の後半の「認証されていない要求」セクションで指定します。

このオプションを使用すると、アプリで認証コードを記述する必要はまったくありません。ユーザーの要求を調べることで、ロール固有の承認など、より細かい承認を処理できます。

注意事項

この方法でのアクセスの制限は、アプリへのすべての呼び出しに適用されますが、これは、多くのシングルページアプリケーションのように、一般公開されているホームページを必要とするアプリには適切でない場合があります。例外が必要な場合は、構成ファイルで除外されたパスを構成する必要があります。

注

組織内のユーザーに対して Microsoft ID プロバイダーを使用する場合は、既定の動作として、Microsoft Entra テナント内のどのユーザーでもアプリケーションのトークンを要求できます。アプリへのアクセスを定義されている一連のユーザーに制限したい場合は、Microsoft Entra でアプリケーションを構成できます。 App Service には、いくつかの検証に役立つ場合がある基本的な組み込み認可チェックも用意されています。 Microsoft Entra での認可について詳しくは、Microsoft Entra の認可の基本に関する記事をご覧ください。

組織内のユーザーに対して Microsoft ID プロバイダーを使用している場合の既定の動作は、Microsoft Entra テナント内のすべてのユーザーがアプリケーションのトークンを要求できることです。アプリへのアクセスを定義されている一連のユーザーに制限したい場合は、Microsoft Entra でアプリケーションを構成できます。 App Service には、いくつかの検証に役立つ基本的な組み込み承認チェックも用意されています。 Microsoft Entra での認可について詳しくは、Microsoft Entra の認可の基本に関する記事をご覧ください。

認証されていない要求

HTTP 302 Found リダイレクト: ウェブサイトに推奨: 設定されたアイデンティティプロバイダのいずれかにアクションをリダイレクトします。このような場合、ブラウザークライアントは、選択したプロバイダーの /.auth/login/<provider> にリダイレクトされます。
HTTP 401 Unauthorized: API向けに推奨される: 匿名のリクエストがネイティブモバイルアプリから来た場合に、HTTP 401 Unauthorizedの応答を返します。また、拒否をすべての要求に対して HTTP 401 Unauthorized するように構成することもできます。
HTTP 403 禁止: すべての要求に対して拒否を HTTP 403 Forbidden するように構成します。
HTTP 404 Not found: 拒否がすべての要求に対して HTTP 404 Not found されるように構成します。

トークンストア

App Service には、組み込みのトークンストアが用意されています。トークンストアは、Web アプリ、API、またはネイティブモバイルアプリのユーザーに関連付けられているトークンのリポジトリです。いずれかのプロバイダーで認証を有効にすると、このトークンストアはアプリですぐに使用できるようになります。

アプリケーションコードがユーザーの代わりにこれらのプロバイダーのデータにアクセスする必要がある場合は、通常、アプリケーションでこれらのトークンを収集、格納、更新するためのコードを記述する必要があります。アクションには、次のものが含まれます。

認証済みユーザーの Facebook タイムラインに投稿します。
Microsoft Graph API を使用して、ユーザーの企業データを読み取る。

トークンストアに関しては、トークンが必要になったらトークンを取得し、トークンが無効になったらトークンを更新するよう App Service に指示するだけです。

ID トークン、アクセストークン、および更新トークンは、認証されたセッション用にキャッシュされます。それらにアクセスできるのは、関連付けられているユーザーだけです。

アプリでトークンを操作する必要がない場合は、アプリの >] ページでトークンストアを無効にすることができます。

ロギングとトレース

アプリケーションのログ記録を有効にすると、認証トレースと承認トレースがログファイルに直接表示されます。予期しない認証エラーが発生した場合は、既存のアプリケーションログを参照して、すべての詳細を簡単に確認できます。

失敗した要求トレースを有効にした場合、失敗した要求で認証と承認モジュールが果たす可能性があるロールを正確に確認できます。トレースログでは、EasyAuthModule_32/64 という名前のモジュールへの参照を探します。

クロスサイトリクエストフォージェリの軽減策

App Service 認証では、次の条件に対してクライアント要求を検査することで、クロスサイトリクエストフォージェリが軽減されます。

これは、セッション Cookie を介して認証された POST 要求です。
要求は、HTTP User-Agent ヘッダーによって決定された既知のブラウザーから送信されました。
HTTP Origin ヘッダーまたは HTTP Referer ヘッダーが見つからないか、リダイレクト用に承認された外部ドメインの構成済みリストに含まれていない。
HTTP Origin ヘッダーが見つからないか、クロスオリジンリソース共有 (CORS) の配信元の構成済みリストに含まれていません。

要求がこれらの条件をすべて満たす場合、App Service 認証によって自動的に拒否されます。この軽減ロジックを回避するには、設定>認証>編集認証設定>許可された外部リダイレクト URL のリダイレクトリストに外部ドメインを追加します。

Azure Front Door の使用に関する考慮事項

Azure Front Door またはその他のリバースプロキシの背後にある認証で Azure App Service を使用している場合は、次のアクションを検討してください。

Azure Front Door のキャッシュを無効にする

認証ワークフローの Azure Front Door キャッシュを無効にします。

リダイレクトに Azure Front Door エンドポイントを使用する

App Service は、通常、Azure Front Door によって公開されている場合は直接アクセスできません。この動作を防ぐには、たとえば、Azure Front Door Premium で Azure Private Link を使用して App Service を公開します。認証ワークフローがトラフィックを App Service に直接リダイレクトしないようにするため。詳細については、「リダイレクト URI」を参照してください。

App Service で適切なリダイレクト URI が使用されていることを確認する

一部の構成では、App Service は Azure Front Door FQDN ではなく、その完全修飾ドメイン名 (FQDN) をリダイレクト URI として使用します。この構成により、クライアントが Azure Front Door ではなく App Service にリダイレクトされるときに問題が発生します。これを変更するには、forwardProxy を Standard に設定し、Azure Front Door が設定した X-Forwarded-Host ヘッダーを App Service が考慮するようにします。

Azure Application Gateway や Microsoft 以外の製品などの他のリバースプロキシでは、異なるヘッダーが使用され、別の forwardProxy 設定が必要になる場合があります。

Azure portal を使用して forwardProxy 構成を変更することはできません。 az restを使用する必要があります。

設定のエクスポート

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

設定を更新する

検索対象:

"httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

conventionが、Azure Front Door で使用されるStandard ヘッダーを考慮してX-Forwarded-Hostに設定されていることを確認します。

設定のインポート

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

App Service 認証の詳細については、次を参照してください。

サンプルについては、以下を参照してください。

クイックスタート: Azure App Service で実行されている Web アプリにアプリ認証を追加する
チュートリアル: Azure App Service でエンドツーエンドでユーザーを認証および承認する
Azure AppService Easy Auth の .NET Core 統合 (Microsoft 以外の GitHub コンテンツ)
.NET Core での Azure App Service 認証の使用 (Microsoft 以外の GitHub コンテンツ)