App Service の認証と承認について詳しく知る

3 分

Azure App Service は組み込みの認証と認可のサポートを提供するので、Web アプリ、RESTful API、モバイルバックエンド、Azure Functions で最小限のコードを記述するだけで、またはまったく記述せずに、ユーザーのサインインとデータへのアクセスを可能にできます。

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

認証と承認に App Service を必ず使う必要はありません。多くの Web フレームワークにセキュリティ機能がバンドルされており、必要に応じてそれらを使うことができます。 App Service 以上に高い柔軟性が必要な場合は、独自のユーティリティを記述することもできます。

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

Azure App Service では、独自に実装せず、さまざまな認証機能を Web アプリまたは API に統合できます。
これはプラットフォームに直接組み込まれており、いかなる特定の言語、SDK、セキュリティの専門知識、コードも必要ありません。
複数のログインプロバイダーを統合できます。たとえば、Microsoft Entra ID、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 ログイン
GitHub	`/.auth/login/github`	App Service GitHub ログイン

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

しくみ

認証と承認のモジュールは、アプリケーションのコードと同じサンドボックスで実行します。有効になっている場合、すべての受信 HTTP 要求は、アプリケーションコードによって処理される前に、認証と認可のモジュールを通過します。このモジュールは、アプリのためにいくつかの処理を行います。

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

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

注意

Linux コンテナーでは、認証と承認のモジュールは、アプリケーションのコードから分離された別のコンテナーで実行されます。インプロセスでは実行されないため、特定の言語フレームワークと直接統合することはできません。

Authentication flow

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

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

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

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

注意事項

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

トークンストア

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

ログとトレース

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

続行