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

[アーティクル]
09/27/2024

Note

2024 年 6 月 1 日より、新しく作成されたすべての App Service アプリには、名前付け規則 <app-name>-<random-hash>.<region>.azurewebsites.net を使用して一意の既定のホスト名を生成するオプションが備わります。既存のアプリ名は変更されません。

例: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

詳細については、App Service リソースの一意の既定のホスト名に関するページを参照してください。

Azure App Service は組み込みの認証と認可の機能 (Easy Auth (簡単認証) と呼ばれることもあります) を提供するので、Web アプリ、RESTful API、モバイルバックエンド、さらには Azure Functions でも、最小限のコードを記述するだけで、またはまったく記述せずに、ユーザーのサインインとデータへのアクセスを可能にできます。この記事では、App Service によりアプリの認証と認可を簡略化する方法について説明します。

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

認証と認可にこの機能を必ずしも使う必要はありません。選択した Web フレームワークにバンドルされているセキュリティ機能を使用するか、独自のユーティリティを作成することができます。ただし、最新のセキュリティ、プロトコル、ブラウザーの更新プログラムを使用して、ソリューションが最新の状態に保たれていることを確認する必要があります。

認証 (サインインユーザー) と認可 (セキュリティで保護されたデータへのアクセスの提供) に対して、セキュリティで保護されたソリューションを実装するには、かなりの労力が必要になることがあります。業界のベストプラクティスと標準に従って、実装を最新の状態に保つ必要があります。 App Service と Azure Functions 用の組み込みの認証機能では、すぐに使用できる認証をフェデレーション ID プロバイダーに提供することで、時間と労力を節約できます。これにより、アプリケーションの残りの部分に専念できます。

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

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

ID プロバイダー

App Service が使用するフェデレーション ID では、サードパーティの ID プロバイダーが代わりにユーザー ID と認証フローを管理します。次の ID プロバイダーを既定で利用できます。

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

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

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

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

App Service は、サイトのコンテンツと API へのアクセスを制限することなく、認証に使用できます。アクセス制限は、Web アプリの [認証]>[認証設定] セクションで設定できます。認証されたユーザーのみにアプリのアクセスを制限するには、構成された ID プロバイダーのいずれかでログインできるように [要求が認証されない場合に実行するアクション] を設定します。アクセスを制限しないで認証するには、 [要求が認証されない場合に実行するアクション] を [匿名要求を許可する (操作不要)] に設定します。

重要

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

しくみ

機能のアーキテクチャ

認証と認可のミドルウェアコンポーネントは、アプリケーションと同じ VM で実行されるプラットフォームの機能です。これが有効になっている場合、すべての受信 HTTP 要求は、アプリケーションによって処理される前に通過します。

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

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

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

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

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

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

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

Authentication flow

認証フローは、プロバイダーによる違いはありませんが、プロバイダーの SDK でサインインするかどうかによって異なります。

プロバイダーの SDK を使わない場合:アプリケーションは、フェデレーションサインインを App Service に委任します。これはブラウザーアプリで通常のケースであり、プロバイダーのログインページをユーザーに表示することができます。サーバーのコードがサインインプロセスを管理するので、"サーバー主導のフロー" または "サーバーフロー" とも呼ばれます。このケースは、認証に埋め込みブラウザーが使用されるブラウザーアプリとモバイルアプリに適用されます。
プロバイダーの SDK を使う場合:アプリケーションは、ユーザーを手動でプロバイダーにサインインさせてから、検証のために App Service に認証トークンを送信します。これはブラウザーレスアプリで通常のケースであり、プロバイダーのサインインページをユーザーに表示することはできません。アプリケーションのコードがサインインプロセスを管理するので、"クライアント主導のフロー" または "クライアントフロー" とも呼ばれます。このケースは、REST API、Azure Function、JavaScript ブラウザークライアント、およびいっそう柔軟なサインインプロセスを必要とするブラウザーアプリに適用されます。また、プロバイダーの SDK を使ってユーザーをサインインさせるネイティブモバイルアプリにも適用されます。

App Service または Azure Functions の別の REST API への App Service 内の信頼されたブラウザーアプリからの呼び出しは、サーバー主導のフローを使って認証することができます。詳細については、「サインインとサインアウトのカスタマイズ」に関するページを参照してください。

次の表では、認証フローの手順を示します。

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

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

認可の動作

重要

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

Azure portal では、受信要求が認証されていない場合、複数の動作で App Service を構成することができます。以下の見出しではそれらのオプションを説明します。

アクセスの制限

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

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

このオプションを使用すると、アプリで認証コードを記述する必要はまったくありません。役割固有の認可などのさらに細かい認可は、ユーザーの要求を調べることで処理できます (「ユーザー要求へのアクセス」をご覧ください)。

注意事項

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

Note

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

認証されていない要求

[HTTP 302 リダイレクトが見つかりました: Web サイトに推奨] 構成されている ID プロバイダーのいずれかにアクションをリダイレクトします。このような場合は、選択したプロバイダーの /.auth/login/<provider> にブラウザークライアントがリダイレクトされます。
[HTTP 401 認可されていない: API に推奨] 匿名要求がネイティブモバイルアプリからのものである場合、返される応答は HTTP 401 Unauthorized です。すべての要求に対し拒否を HTTP 401 Unauthorized として構成することもできます。
[HTTP 403 許可されていない] すべての要求に対し拒否を HTTP 403 Forbidden として構成します。
[HTTP 404 未検出] すべての要求に対し拒否を HTTP 404 Not found として構成します。

トークンストア

App Service が提供する組み込みのトークンストアは、Web アプリ、API、またはネイティブモバイルアプリのユーザーに関連付けられているトークンのリポジトリです。いずれかのプロバイダーで認証を有効にすると、このトークンストアはアプリですぐに使用できるようになります。次のような場合、アプリケーションコードはユーザーに代わってこれらのプロバイダーのデータにアクセスする必要があります。

認証されたユーザーの Facebook タイムラインに投稿する
Microsoft Graph API を使用してユーザーの会社のデータを読み取る

通常、アプリケーションでこれらのトークンを収集、格納、更新するには、コードを記述する必要があります。トークンストアに関しては、トークンが必要になったらトークンを取得し、トークンが無効になったらトークンを更新するよう App Service に指示するだけです。

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

お使いのアプリでトークンを使う必要がない場合は、お使いのアプリの認証と承認のページでトークンストアを無効にできます。

ログとトレース

アプリケーションログを有効にすると、認証と認可のトレースをログファイルで直接見ることができます。予期しない認証エラーが発生した場合は、既存のアプリケーションログを参照して、すべての詳細を簡単に確認できます。失敗した要求トレースを有効にしてある場合は、失敗した要求で認証および認可モジュールが演じていた役割を正確に確認できます。トレースログでは、EasyAuthModule_32/64 という名前のモジュールへの参照を探します。

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

App Service 認証では、次の条件についてクライアント要求を検査することで CSRF を軽減します。

セッション Cookie を使用して認証された POST 要求である。
要求は既知のブラウザー (HTTP User-Agent ヘッダーによって判断される) から送信された。
HTTP Origin または HTTP Referer ヘッダーが見つからないか、リダイレクト用に承認された外部ドメインの構成済み一覧に含まれていない。
HTTP Origin ヘッダーが見つからないか、CORS origin の構成済み一覧に含まれていない。

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

Azure Front Door を使用する場合の考慮事項

Azure Front Door やその他のリバースプロキシの背後で認証を行う Azure App Service を使用する場合は、さらにいくつかの点を考慮する必要があります。

認証ワークフローの Front Door キャッシュを無効にします。
リダイレクトに Front Door エンドポイントを使用します。

通常、Azure Front Door 経由で公開されている場合は、App Service には直接アクセスできません。これを抑止するには、たとえば、Azure Front Door Premium で Private Link を介して App Service を公開します。認証ワークフローでトラフィックが App Service に直接リダイレクトで戻されないようにするには、アプリケーションでリダイレクト先を https://<front-door-endpoint>/.auth/login/<provider>/callback とするよう構成することが重要です。
App Service で適切なリダイレクト URI が使用されていることを確認する

一部の構成では、App Service で Front Door FQDN ではなく App Service FQDN をリダイレクト URI として使用しています。この場合、クライアントが Front Door ではなく App Service にリダイレクトされるときに問題が発生します。これを変更するには、forwardProxy の設定を Standard に設定して、App Service で、Azure Front Door によって設定される X-Forwarded-Host ヘッダーを優先させる必要があります。

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

この構成は、現時点では Azure portal を介して行うことはできません。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 が Standard に設定されており、Azure Front Door で使用される 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

その他のリソース

サンプル:

次の方法で共有

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

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

ID プロバイダー

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

しくみ

機能のアーキテクチャ

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

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

Authentication flow

認可の動作

トークンストア

ログとトレース

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

Azure Front Door を使用する場合の考慮事項

その他のリソース

フィードバック

その他のリソース

次の方法で共有

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

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

ID プロバイダー

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

しくみ

機能のアーキテクチャ

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

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

Authentication flow

認可の動作

トークン ストア

ログとトレース

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

Azure Front Door を使用する場合の考慮事項

その他のリソース

フィードバック

その他のリソース

トークンストア

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