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

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 プロバイダーを既定で利用できます。

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

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

この機能を有効にすると、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 内の信頼されたブラウザー アプリからの呼び出しは、サーバー主導のフローを使って認証することができます。 詳細については、「サインインとサインアウトのカスタマイズ」に関するページを参照してください。

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

クライアント ブラウザーの場合、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 を使用する場合は、さらにいくつかの点を考慮する必要があります。

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

  Azure 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

その他のリソース

• 方法: Microsoft Entra ログインを使用するように App Service または Azure Functions アプリを構成する
• サインインとサインアウトのカスタマイズ

• OAuth トークンとセッションの使用
• ユーザーおよびアプリケーション要求にアクセスする
• ファイルベースの構成

サンプル:

• チュートリアル:Azure App Service で実行されている Web アプリに認証を追加する
• チュートリアル: Azure App Service (Windows または Linux) でユーザーをエンド ツー エンドで認証および認可する
• Azure AppService EasyAuth の .NET Core 統合 (サードパーティ)
• .NET Core を使用した Azure App Service 認証の取得 (サードパーティ)