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、セキュリティの専門知識、使用するコードも必要ありません。
  • 複数のログイン プロバイダーを統合できます。 たとえば、Azure AD、Facebook、Google、Twitter などです。

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 ログイン
任意の OpenID Connect プロバイダー (プレビュー) /.auth/login/<providerName> App Service OpenID Connect ログイン

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

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

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

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

注意

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

しくみ

機能のアーキテクチャ

Authentication flow

認可の動作

トークン ストア

ログとトレース

機能のアーキテクチャ

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

デプロイされたサイトへのトラフィックを許可する前に、ID プロバイダーと対話するサイト サンドボックス内のプロセスによってインターセプトされる要求を示すアーキテクチャ図

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

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

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

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

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

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

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

Authentication flow

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

  • プロバイダーの SDK を使わない場合:アプリケーションは、フェデレーション サインインを App Service に委任します。 これはブラウザー アプリで通常のケースであり、プロバイダーのログイン ページをユーザーに表示することができます。 サーバーのコードがサインイン プロセスを管理するので、"サーバー主導のフロー" または "サーバー フロー" とも呼ばれます。 このケースはブラウザー アプリに適用されます。 また、Mobile Apps クライアント SDK を使ってユーザーをサインインさせるネイティブ アプリにも適用されます。その場合は、SDK が Web ビューを開いて 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 ヘッダーで認証トークンを提示します (Mobile Apps クライアント SDK によって自動的に処理されます)。

クライアント ブラウザーの場合、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 になるように拒否を構成することもできます。

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

注意事項

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

注意

既定では、Azure AD テナント内のすべてのユーザーが Azure AD にアプリケーションのトークンを要求できます。 定義されている一連のユーザーに対してアプリへのアクセスを制限する場合は、Azure AD でアプリケーションを構成できます。

トークン ストア

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

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

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

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

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

ログとトレース

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

その他のリソース

サンプル: