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 ID、Facebook、Google、Twitter などです。

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

ID プロバイダー

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

プロバイダー サインイン エンドポイント 使用方法に関するガイダンス
Microsoft ID プラットフォーム /.auth/login/aad App Service Microsoft ID プラットフォーム ログイン
Facebook /.auth/login/facebook App Service Facebook ログイン
Google /.auth/login/google App Service Google ログイン
Twitter /.auth/login/twitter App Service Twitter ログイン
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 へのアクセスを制限することなく、認証に使用できます。 認証されたユーザーのみにアプリのアクセスを制限するには、構成された ID プロバイダーのいずれかでログインできるように [要求が認証されない場合に実行するアクション] を設定します。 アクセスを制限しないで認証するには、 [要求が認証されない場合に実行するアクション] を [匿名要求を許可する (操作不要)] に設定します。

重要

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

しくみ

機能のアーキテクチャ

認証フロー

認可の動作

トークン ストア

ログとトレース

機能のアーキテクチャ

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

An architecture diagram showing requests being intercepted by a process in the site sandbox which interacts with identity providers before allowing traffic to the deployed site

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

  • 指定された 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 ヘッダーで認証情報も渡します。

このオプションでは、匿名要求をいっそう柔軟に処理できます。 たとえば、ユーザーに複数のサインイン プロバイダーを提示することができます。 ただし、コードを記述する必要があります。

認証を必須にする

このオプションでは、アプリケーションへの認証されていないトラフィックを拒否します。 この拒否は、構成されているいずれかの ID プロバイダーへのリダイレクト操作になります。 このような場合は、選択したプロバイダーの /.auth/login/<provider> にブラウザー クライアントがリダイレクトされます。 匿名要求がネイティブ モバイル アプリからのものである場合、返される応答は HTTP 401 Unauthorized です。 すべての要求に対して HTTP 401 Unauthorized または HTTP 403 Forbidden になるように拒否を構成することもできます。

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

注意事項

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

Note

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

トークン ストア

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

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

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

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

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

ログとトレース

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

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

Azure Front Door やその他のリバース プロキシの背後で Easy Auth で Azure App Service を使用する場合は、考慮する必要がある追加の事項がいくつかあります。

  1. 認証ワークフローのキャッシュを無効にする

    Azure Front Door でルールを構成して認証と認可に関連するページでキャッシュを無効にする方法の詳細については、「認証ワークフローのキャッシュを無効にする」を参照してください。

  2. リダイレクトに 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 とするよう構成することが重要です。

  3. 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"
      }
    }
    

    conventionStandard に設定されており、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

その他のリソース

サンプル: