Azure App Service および Azure Functions での認証と承認Authentication and authorization in Azure App Service and Azure Functions


現時点では、現在のユーザーに Authentication/Authorization 機能を設定することは ASP.NET Core ではサポートされていません。At this time, ASP.NET Core does not currently support populating the current user with the Authentication/Authorization feature.

Azure App Service は組み込みの認証と認可のサポートを提供するので、Web アプリ、RESTful API、モバイル バックエンド、さらには Azure Functions でも、最小限のコードを記述するだけで、またはまったく記述せずに、ユーザーのサインインとデータへのアクセスを可能にできます。Azure App Service provides built-in authentication and authorization support, so you can sign in users and access data by writing minimal or no code in your web app, RESTful API, and mobile back end, and also Azure Functions. この記事では、App Service によりアプリの認証と認可を簡略化する方法について説明します。This article describes how App Service helps simplify authentication and authorization for your app.

安全な認証と認可には、フェデレーション、暗号化、JSON Web トークン (JWT) 管理、付与タイプなど、セキュリティについての深い理解が必要です。Secure authentication and authorization require deep understanding of security, including federation, encryption, JSON web tokens (JWT) management, grant types, and so on. App Service ではこれらのユーティリティが提供されているので、ビジネス価値を顧客に提供することにいっそうの時間と労力を費やすことができます。App Service provides these utilities so that you can spend more time and energy on providing business value to your customer.


認証と認可にこの機能を必ずしも使う必要はありません。You're not required to use this feature for authentication and authorization. 選択した Web フレームワークにバンドルされているセキュリティ機能を使用するか、独自のユーティリティを作成することができます。You can use the bundled security features in your web framework of choice, or you can write your own utilities. ただし、Chrome 80 では Cookie の SameSite の実装に破壊的変更が加えられているため (リリース日は 2020 年 3 月頃)、クライアントの Chrome ブラウザーが更新されると、クロスサイト Cookie の投稿に依存するカスタムのリモート認証またはその他のシナリオが動作しなくなる可能性があることに注意してください。However, keep in mind that Chrome 80 is making breaking changes to its implementation of SameSite for cookies (release date around March 2020), and custom remote authentication or other scenarios that rely on cross-site cookie posting may break when client Chrome browsers are updated. この回避策は複雑です。ブラウザーごとに異なる SameSite 動作をサポートする必要があるためです。The workaround is complex because it needs to support different SameSite behaviors for different browsers.

App Service でホストされている ASP.NET Core 2.1 以降のバージョンには、この破壊的変更に対する修正プログラムが既に適用されており、Chrome 80 以前のブラウザーが適切に処理されます。The ASP.NET Core 2.1 and above versions hosted by App Service are already patched for this breaking change and handle Chrome 80 and older browsers appropriately. さらに、ASP.NET Framework 4.7.2 用の同じ修正プログラムは、2020 年 1 月中に App Service インスタンスに展開されています。In addition, the same patch for ASP.NET Framework 4.7.2 is being deployed on the App Service instances throughout January 2020. お使いのアプリが修正プログラムを受け取ったかどうかを確認する方法など、詳細については、Azure App Service の SameSite の Cookie の更新プログラムに関する記事を参照してください。For more information, including how to know if your app has received the patch, see Azure App Service SameSite cookie update.

ネイティブ モバイル アプリに固有の情報については、Azure App Service でのモバイル アプリ用のユーザー認証と認可に関する記事をご覧ください。For information specific to native mobile apps, see User authentication and authorization for mobile apps with Azure App Service.

しくみHow it works

認証と認可のモジュールは、アプリケーションのコードと同じサンドボックスで実行します。The authentication and authorization module runs in the same sandbox as your application code. 有効になっている場合、すべての受信 HTTP 要求は、アプリケーション コードによって処理される前に、認証と認可のモジュールを通過します。When it's enabled, every incoming HTTP request passes through it before being handled by your application code.

このモジュールは、アプリのためにいくつかの処理を行います。This module handles several things for your app:

  • 指定されたプロバイダーでユーザーを認証しますAuthenticates users with the specified provider
  • トークンを検証、格納、更新しますValidates, stores, and refreshes tokens
  • 認証されたセッションを管理しますManages the authenticated session
  • 要求ヘッダーに ID 情報を挿入しますInjects identity information into request headers

このモジュールはアプリケーションのコードとは別に実行され、アプリの設定を使って構成されます。The module runs separately from your application code and is configured using app settings. SDK、特定の言語、またはアプリケーションのコードの変更は必要ありません。No SDKs, specific languages, or changes to your application code are required.

ユーザー/アプリケーション要求User/Application claims

すべての言語フレームワークにおいて、App Service は、受信トークン (認証されたエンド ユーザーまたはクライアント アプリケーションからなど) 内のクレームを要求ヘッダーに挿入することにより、コードで使用できるようにします。For all language frameworks, App Service makes the claims in the incoming token (whether that be from an authenticated end user or a client application) available to your code by injecting them into the request headers. ASP.NET 4.6 アプリの場合、App Service は認証されたユーザーの要求で ClaimsPrincipal.Current を設定するので、標準の .NET コード パターン ([Authorize] 属性など) に従うことができます。For ASP.NET 4.6 apps, App Service populates ClaimsPrincipal.Current with the authenticated user's claims, so you can follow the standard .NET code pattern, including the [Authorize] attribute. 同様に、PHP アプリの場合、App Service は _SERVER['REMOTE_USER'] 変数を設定します。Similarly, for PHP apps, App Service populates the _SERVER['REMOTE_USER'] variable. Java アプリの場合、要求には Tomcat サーブレットからアクセスできますFor Java apps, the claims are accessible from the Tomcat servlet.

Azure Functions では、.NET コードの ClaimsPrincipal.Current は設定されていませんが、要求ヘッダーでユーザーの要求を検索することも、要求コンテキストまたはバインディング パラメーターを使用して ClaimsPrincipal オブジェクトを取得することもできます。For Azure Functions, ClaimsPrincipal.Current is not populated for .NET code, but you can still find the user claims in the request headers, or get the ClaimsPrincipal object from the request context or even through a binding parameter. 詳細については、「クライアント ID の操作」を参照してください。See working with client identities for more information.

詳しくは、「ユーザー要求へのアクセス」をご覧ください。For more information, see Access user claims.

トークン ストアToken store

App Service が提供する組み込みのトークン ストアは、Web アプリ、API、またはネイティブ モバイル アプリのユーザーに関連付けられているトークンのリポジトリです。App Service provides a built-in token store, which is a repository of tokens that are associated with the users of your web apps, APIs, or native mobile apps. いずれかのプロバイダーで認証を有効にすると、このトークン ストアはアプリですぐに使用できるようになります。When you enable authentication with any provider, this token store is immediately available to your app. 次のような場合、アプリケーション コードはユーザーに代わってこれらのプロバイダーのデータにアクセスする必要があります。If your application code needs to access data from these providers on the user's behalf, such as:

  • 認証されたユーザーの Facebook タイムラインに投稿するpost to the authenticated user's Facebook timeline
  • Microsoft Graph API を使用してユーザーの会社のデータを読み取るread the user's corporate data using the Microsoft Graph API

通常、アプリケーションでこれらのトークンを収集、格納、更新するには、コードを記述する必要があります。You typically must write code to collect, store, and refresh these tokens in your application. トークン ストアに関しては、トークンが必要になったらトークンを取得し、トークンが無効になったらトークンを更新するよう App Service に指示するだけです。With the token store, you just retrieve the tokens when you need them and tell App Service to refresh them when they become invalid.

ID トークン、アクセス トークン、更新トークンは認証されたセッションに対してキャッシュされ、関連付けられているユーザーだけがアクセスできます。The id tokens, access tokens, and refresh tokens are cached for the authenticated session, and they're accessible only by the associated user.

アプリでトークンを使う必要がない場合は、トークン ストアを無効にしてもかまいません。If you don't need to work with tokens in your app, you can disable the token store.

ログとトレースLogging and tracing

アプリケーション ログを有効にすると、認証と認可のトレースをログ ファイルで直接見ることができます。If you enable application logging, you will see authentication and authorization traces directly in your log files. 予期しない認証エラーが発生した場合は、既存のアプリケーション ログを参照して、すべての詳細を簡単に確認できます。If you see an authentication error that you didn't expect, you can conveniently find all the details by looking in your existing application logs. 失敗した要求トレースを有効にしてある場合は、失敗した要求で認証および認可モジュールが演じていた役割を正確に確認できます。If you enable failed request tracing, you can see exactly what role the authentication and authorization module may have played in a failed request. トレース ログでは、EasyAuthModule_32/64 という名前のモジュールへの参照を探します。In the trace logs, look for references to a module named EasyAuthModule_32/64.

ID プロバイダーIdentity providers

App Service が使用するフェデレーション ID では、サード パーティの ID プロバイダーが代わりにユーザー ID と認証フローを管理します。App Service uses federated identity, in which a third-party identity provider manages the user identities and authentication flow for you. 既定では 5 つの ID プロバイダーを利用できます。Five identity providers are available by default:

プロバイダーProvider サインイン エンドポイントSign-in endpoint
Azure Active DirectoryAzure Active Directory /.auth/login/aad
Microsoft アカウントMicrosoft Account /.auth/login/microsoftaccount
FacebookFacebook /.auth/login/facebook
GoogleGoogle /.auth/login/google
TwitterTwitter /.auth/login/twitter

これらのプロバイダーのいずれかで認証と認可を有効にすると、そのプロバイダーのサインイン エンドポイントが、ユーザー認証と、プロバイダーからの認証トークンの検証に使用できるようになります。When you enable authentication and authorization with one of these providers, its sign-in endpoint is available for user authentication and for validation of authentication tokens from the provider. 任意の数のサインイン オプションを、ユーザーに対して簡単に提供できます。You can provide your users with any number of these sign-in options with ease. 別の ID プロバイダーや独自のカスタム ID ソリューションを統合することもできます。You can also integrate another identity provider or your own custom identity solution.

Authentication flowAuthentication flow

認証フローは、プロバイダーによる違いはありませんが、プロバイダーの SDK でサインインするかどうかによって異なります。The authentication flow is the same for all providers, but differs depending on whether you want to sign in with the provider's SDK:

  • プロバイダーの SDK を使わない場合:アプリケーションは、フェデレーション サインインを App Service に委任します。Without provider SDK: The application delegates federated sign-in to App Service. これはブラウザー アプリで通常のケースであり、プロバイダーのログイン ページをユーザーに表示することができます。This is typically the case with browser apps, which can present the provider's login page to the user. サーバーのコードがサインイン プロセスを管理するので、"サーバー主導のフロー" または "サーバー フロー" とも呼ばれます。The server code manages the sign-in process, so it is also called server-directed flow or server flow. このケースはブラウザー アプリに適用されます。This case applies to browser apps. また、Mobile Apps クライアント SDK を使ってユーザーをサインインさせるネイティブ アプリにも適用されます。その場合は、SDK が Web ビューを開いて App Service 認証でユーザーをサインインさせます。It also applies to native apps that sign users in using the Mobile Apps client SDK because the SDK opens a web view to sign users in with App Service authentication.
  • プロバイダーの SDK を使う場合:アプリケーションは、ユーザーを手動でプロバイダーにサインインさせてから、検証のために App Service に認証トークンを送信します。With provider SDK: The application signs users in to the provider manually and then submits the authentication token to App Service for validation. これはブラウザーレス アプリで通常のケースであり、プロバイダーのサインイン ページをユーザーに表示することはできません。This is typically the case with browser-less apps, which can't present the provider's sign-in page to the user. アプリケーションのコードがサインイン プロセスを管理するので、"クライアント主導のフロー" または "クライアント フロー" とも呼ばれます。The application code manages the sign-in process, so it is also called client-directed flow or client flow. このケースは、REST API、Azure Function、JavaScript ブラウザー クライアント、およびいっそう柔軟なサインイン プロセスを必要とするブラウザー アプリに適用されます。This case applies to REST APIs, Azure Functions, and JavaScript browser clients, as well as browser apps that need more flexibility in the sign-in process. また、プロバイダーの SDK を使ってユーザーをサインインさせるネイティブ モバイル アプリにも適用されます。It also applies to native mobile apps that sign users in using the provider's SDK.


App Service または Azure Functions の別の REST API への App Service 内の信頼されたブラウザー アプリからの呼び出しは、サーバー主導のフローを使って認証することができます。Calls from a trusted browser app in App Service to another REST API in App Service or Azure Functions can be authenticated using the server-directed flow. 詳細については、「Azure App Service での認証と認可のカスタマイズ」を参照してください。For more information, see Customize authentication and authorization in App Service.

次の表では、認証フローの手順を示します。The table below shows the steps of the authentication flow.

手順Step プロバイダーの SDK を使わない場合Without provider SDK プロバイダーの SDK を使う場合With provider SDK
1.ユーザーをサインインさせる1. Sign user in クライアントを /.auth/login/<provider> にリダイレクトします。Redirects client to /.auth/login/<provider>. クライアント コードはプロバイダーの SDK でユーザーを直接サインインさせ、認証トークンを受け取ります。Client code signs user in directly with provider's SDK and receives an authentication token. 詳しくは、プロバイダーのドキュメントをご覧ください。For information, see the provider's documentation.
2.認証をポストする2. Post-authentication プロバイダーはクライアントを /.auth/login/<provider>/callback にリダイレクトします。Provider redirects client to /.auth/login/<provider>/callback. クライアント コードは検証のためにプロバイダーからのトークンを /.auth/login/<provider> にポストします。Client code posts token from provider to /.auth/login/<provider> for validation.
3.認証済みのセッションを確立する3. Establish authenticated session App Service は認証された Cookie を応答に追加します。App Service adds authenticated cookie to response. App Service は独自の認証トークンをクライアント コードに返します。App Service returns its own authentication token to client code.
4.認証済みのコンテンツを提供する4. Serve authenticated content クライアントは以降の要求に認証クッキーを含めます (ブラウザーによって自動的に処理されます)。Client includes authentication cookie in subsequent requests (automatically handled by browser). クライアント コードは X-ZUMO-AUTH ヘッダーで認証トークンを提示します (Mobile Apps クライアント SDK によって自動的に処理されます)。Client code presents authentication token in X-ZUMO-AUTH header (automatically handled by Mobile Apps client SDKs).

クライアント ブラウザーの場合、App Service は認証されていないすべてのユーザーを /.auth/login/<provider> に自動的に送ることができます。For client browsers, App Service can automatically direct all unauthenticated users to /.auth/login/<provider>. また、ユーザーが選んだプロバイダーを使ってアプリにサインインするための 1 つまたは複数の /.auth/login/<provider> リンクをユーザーに表示することもできます。You can also present users with one or more /.auth/login/<provider> links to sign in to your app using their provider of choice.

認可の動作Authorization behavior

Azure portal では、受信要求が認証されていない場合、複数の動作で App Service の認可を構成することができます。In the Azure portal, you can configure App Service authorization with a number of behaviors when incoming request is not authenticated.

以下の見出しではそれらのオプションを説明します。The following headings describe the options.

匿名要求を許可する (操作不要)Allow Anonymous requests (no action)

このオプションでは、認証されていないトラフィックの認証がアプリケーション コードに委ねられます。This option defers authorization of unauthenticated traffic to your application code. 認証された要求について、App Service は HTTP ヘッダーで認証情報も渡します。For authenticated requests, App Service also passes along authentication information in the HTTP headers.

このオプションでは、匿名要求をいっそう柔軟に処理できます。This option provides more flexibility in handling anonymous requests. たとえば、ユーザーに複数のサインイン プロバイダーを提示することができます。For example, it lets you present multiple sign-in providers to your users. ただし、コードを記述する必要があります。However, you must write code.

認証された要求のみを許可するAllow only authenticated requests

オプションは [<プロバイダー> でのログイン] です。The option is Log in with <provider>. App Service は、すべての匿名要求を、選ばれたプロバイダーの /.auth/login/<provider> にリダイレクトします。App Service redirects all anonymous requests to /.auth/login/<provider> for the provider you choose. 匿名要求がネイティブ モバイル アプリからのものである場合、返される応答は HTTP 401 Unauthorized です。If the anonymous request comes from a native mobile app, the returned response is an HTTP 401 Unauthorized.

このオプションを使用すると、アプリで認証コードを記述する必要はまったくありません。With this option, you don't need to write any authentication code in your app. 役割固有の認可などのさらに細かい認可は、ユーザーの要求を調べることで処理できます (「ユーザー要求へのアクセス」をご覧ください)。Finer authorization, such as role-specific authorization, can be handled by inspecting the user's claims (see Access user claims).


この方法でのアクセスの制限は、アプリへのすべての呼び出しに適用されますが、これは、多くのシングルページ アプリケーションのように、一般公開されているホーム ページを必要とするアプリには適切でない場合があります。Restricting access in this way applies to all calls to your app, which may not be desirable for apps wanting a publicly available home page, as in many single-page applications.


Authentication/Authorization は、以前は Easy Auth と呼ばれていました。Authentication/Authorization was previously known as Easy Auth.

その他のリソースMore resources

チュートリアル:Azure App Service (Windows) でユーザーをエンド ツー エンドで認証および認可するTutorial: Authenticate and authorize users end-to-end in Azure App Service (Windows)
チュートリアル:Linux 用 Azure App Service でユーザーをエンド ツー エンドで認証および認可するTutorial: Authenticate and authorize users end-to-end in Azure App Service for Linux
App Service での認証と認可のカスタマイズ Azure AppService EasyAuth の .NET Core 統合 (サード パーティ) .NET Core で Azure App Service 認証を使用する (サード パーティ)Customize authentication and authorization in App Service .NET Core integration of Azure AppService EasyAuth (3rd party) Getting Azure App Service authentication working with .NET Core (3rd party)

プロバイダー固有の手順ガイド:Provider-specific how-to guides: