Azure App Service での認証および認可Authentication and authorization in Azure App Service

注意

現時点では、Azure App Service および Azure Functions で AAD V2 (MSAL を含む) はサポートされていません。At this time, AAD V2 (including MSAL) is not supported for Azure App Services and Azure Functions. 更新プログラムがないかどうか確認してください。Please check back for updates.

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.

注意

認証と認可に App Service を必ず使う必要はありません。You're not required to use App Service for authentication and authorization. 多くの Web フレームワークにセキュリティ機能がバンドルされており、必要に応じてそれらを使うことができます。Many web frameworks are bundled with security features, and you can use them if you like. App Service より高い柔軟性が必要な場合は、独自のユーティリティを記述することもできます。If you need more flexibility than App Service provides, you can also write your own utilities.

ネイティブ モバイル アプリに固有の情報については、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 claims

すべての言語フレームワークで、App Service はユーザーの要求を要求ヘッダーに挿入することによってコードで要求を使用できるようにします。For all language frameworks, App Service makes the user's claims 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 では、ClaimsPrincipal.Current は .NET コードに対してハイドレートされませんが、それでも要求ヘッダー内でユーザーの要求を見つけることができます。For Azure Functions, ClaimsPrincipal.Current is not hydrated for .NET code, but you can still find the user claims in the request headers.

詳しくは、「ユーザー要求へのアクセス」をご覧ください。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
  • Azure Active Directory Graph API や Microsoft Graph などからユーザーの会社データを読み取るread the user's corporate data from the Azure Active Directory Graph API or even the Microsoft Graph

通常、アプリケーションでこれらのトークンを収集、格納、更新するには、コードを記述する必要があります。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 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 calls 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.

その他のリソース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 での認証と認可のカスタマイズCustomize authentication and authorization in App Service

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