Azure App Service 上での認証と承認の高度な使用方法Advanced usage of authentication and authorization in Azure App Service

この記事では、App Service 上で組み込みの認証と承認をカスタマイズする方法と、アプリケーションから ID を管理する方法について説明します。This article shows you how to customize the built-in authentication and authorization in App Service, and to manage identity from your application.

すぐに開始するには、以下のチュートリアルのいずれかをご覧ください。To get started quickly, see one of the following tutorials:

複数のサインイン プロバイダーを使用するUse multiple sign-in providers

ポータル構成では、ユーザーに複数 (Facebook と Twitter の両方など) のサインイン プロバイダーを表示するターンキー手法は提供されません。The portal configuration doesn't offer a turn-key way to present multiple sign-in providers to your users (such as both Facebook and Twitter). ただし、この機能をアプリに追加することは難しくありません。However, it isn't difficult to add the functionality to your app. 手順の概要は次のとおりです。The steps are outlined as follows:

最初に、Azure Portal の [認証/承認] ページで、有効にする各 ID プロバイダーを構成します。First, in the Authentication / Authorization page in the Azure portal, configure each of the identity provider you want to enable.

[要求が認証されない場合に実行するアクション] で、 [匿名要求を許可する (操作不要)] を選択します。In Action to take when request is not authenticated, select Allow Anonymous requests (no action).

サインイン ページ、ナビゲーション バー、またはアプリのその他の任意の場所で、有効にした各プロバイダーへのサインイン リンク (/.auth/login/<provider>) を追加します。In the sign-in page, or the navigation bar, or any other location of your app, add a sign-in link to each of the providers you enabled (/.auth/login/<provider>). 例:For example:

<a href="/.auth/login/aad">Log in with Azure AD</a>
<a href="/.auth/login/microsoftaccount">Log in with Microsoft Account</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/twitter">Log in with Twitter</a>

ユーザーがいずれかのリンクをクリックすると、それぞれのサインイン ページが開き、ユーザーがサインインできます。When the user clicks on one of the links, the respective sign-in page opens to sign in the user.

サインイン後のユーザーをカスタム URL にリダイレクトさせるには、post_login_redirect_url クエリ文字列パラメーターを使用します (ご利用の ID プロバイダーの構成におけるリダイレクト URI と混同しないでください)。To redirect the user post-sign-in to a custom URL, use the post_login_redirect_url query string parameter (not to be confused with the Redirect URI in your identity provider configuration). たとえば、サインイン後にユーザーを /Home/Index にリダイレクトさせるには、次の HTML コードを使用します。For example, to navigate the user to /Home/Index after sign-in, use the following HTML code:

<a href="/.auth/login/<provider>?post_login_redirect_url=/Home/Index">Log in</a>

プロバイダーからのトークンを検証するValidate tokens from providers

クライアント主導のサインインでは、アプリケーションはユーザーをプロバイダーに手動でサインインさせ、検証のために認証トークンを App Service に送信します (「Authentication flow」をご覧ください)。In a client-directed sign-in, the application signs in the user to the provider manually and then submits the authentication token to App Service for validation (see Authentication flow). この検証自体では、必要なアプリ リソースへのアクセス権が実際には付与されませんが、検証に成功すると、アプリ リソースへのアクセスに使用できるセッション トークンが付与されます。This validation itself doesn't actually grant you access to the desired app resources, but a successful validation will give you a session token that you can use to access app resources.

プロバイダーのトークンを検証するには、最初に目的のプロバイダーを使用して App Service のアプリが構成されている必要があります。To validate the provider token, App Service app must first be configured with the desired provider. 実行時に、プロバイダーから認証トークンを取得した後、検証のためにトークンを /.auth/login/<provider> にポストします。At runtime, after you retrieve the authentication token from your provider, post the token to /.auth/login/<provider> for validation. 例:For example:

POST https://<appname> HTTP/1.1
Content-Type: application/json


トークンの形式は、プロバイダーによって若干異なります。The token format varies slightly according to the provider. 詳しくは、以下の表をご覧ください。See the following table for details:

プロバイダーの値Provider value 要求本文に必要Required in request body 説明Comments
aad {"access_token":"<access_token>"}
microsoftaccount {"access_token":"<token>"} expires_in プロパティは省略可能です。The expires_in property is optional.
ライブ サービスからトークンを要求する場合は、常に wl.basic スコープを要求します。When requesting the token from Live services, always request the wl.basic scope.
google {"id_token":"<id_token>"} authorization_code プロパティは省略可能です。The authorization_code property is optional. 指定した場合、必要に応じて redirect_uri プロパティを添付することもできます。When specified, it can also optionally be accompanied by the redirect_uri property.
facebook {"access_token":"<user_access_token>"} Facebook からの有効なユーザー アクセス トークンを使用します。Use a valid user access token from Facebook.
twitter {"access_token":"<access_token>", "access_token_secret":"<acces_token_secret>"}

プロバイダー トークンが正常に検証された場合、API は、セッション トークンである authenticationToken を応答本文に入れて戻ります。If the provider token is validated successfully, the API returns with an authenticationToken in the response body, which is your session token.

    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."

このセッション トークンを入手したら、X-ZUMO-AUTH ヘッダーを HTTP 要求に追加することで、保護対象のアプリ リソースにアクセスすることができます。Once you have this session token, you can access protected app resources by adding the X-ZUMO-AUTH header to your HTTP requests. 例:For example:

GET https://<appname>
X-ZUMO-AUTH: <authenticationToken_value>

セッションからサインアウトするSign out of a session

ユーザーは、アプリの /.auth/logout エンドポイントに GET 要求を送信することでサインアウトを開始できます。Users can initiate a sign-out by sending a GET request to the app's /.auth/logout endpoint. GET 要求は次の処理を行います。The GET request does the following:

  • 現在のセッションから認証 Cookie をクリアします。Clears authentication cookies from the current session.
  • トークン ストアから現在のユーザーのトークンを削除します。Deletes the current user's tokens from the token store.
  • Azure Active Directory と Google の場合、ID プロバイダーでサーバー側のサインアウトを実行します。For Azure Active Directory and Google, performs a server-side sign-out on the identity provider.

Web ページの簡単なサインアウト リンクを次に示します。Here's a simple sign-out link in a webpage:

<a href="/.auth/logout">Sign out</a>

既定では、サインアウトに成功すると、クライアントは URL /.auth/logout/done にリダイレクトされます。By default, a successful sign-out redirects the client to the URL /.auth/logout/done. post_logout_redirect_uri クエリ パラメーターを追加して、サインアウト後のリダイレクト ページを変更できます。You can change the post-sign-out redirect page by adding the post_logout_redirect_uri query parameter. 例:For example:

GET /.auth/logout?post_logout_redirect_uri=/index.html

post_logout_redirect_uri の値をエンコードすることをお勧めします。It's recommended that you encode the value of post_logout_redirect_uri.

完全修飾 URL を使用している場合、URL は同じドメインでホストされているか、アプリの許可された外部リダイレクト URL として構成されている必要があります。When using fully qualified URLs, the URL must be either hosted in the same domain or configured as an allowed external redirect URL for your app. 次の例では、同じドメインにホストされていない にリダイレクトします。In the following example, to redirect to that's not hosted in the same domain:

GET /.auth/logout?

Azure Cloud Shell で次のコマンドを実行します。Run the following command in the Azure Cloud Shell:

az webapp auth update --name <app_name> --resource-group <group_name> --allowed-external-redirect-urls ""

URL フラグメントを保持するPreserve URL fragments

ユーザーは、アプリにサインインすると、通常は /wiki/Main_Page#SectionZ のように同じページの同じセクションにリダイレクトされたいと考えます。After users sign in to your app, they usually want to be redirected to the same section of the same page, such as /wiki/Main_Page#SectionZ. ただし、URL フラグメント (たとえば #SectionZ) はサーバーに送信されないため、OAuth のサインインが完了してアプリにリダイレクトされた後は既定で保持されません。However, because URL fragments (for example, #SectionZ) are never sent to the server, they are not preserved by default after the OAuth sign-in completes and redirects back to your app. 目的のアンカーに再度移動する必要がある場合、ユーザー エクスペリエンスは最適ではありません。Users then get a suboptimal experience when they need to navigate to the desired anchor again. この制限は、すべてのサーバー側認証ソリューションに適用されます。This limitation applies to all server-side authentication solutions.

App Service 認証では、OAuth サインイン全体で URL フラグメントを保存できます。In App Service authentication, you can preserve URL fragments across the OAuth sign-in. これを行うには、WEBSITE_AUTH_PRESERVE_URL_FRAGMENT というアプリ設定を true に設定します。To do this, set an app setting called WEBSITE_AUTH_PRESERVE_URL_FRAGMENT to true. Azure portal で行うか、Azure Cloud Shell で次のコマンドを実行するだけです。You can do it in the Azure portal, or simply run the following command in the Azure Cloud Shell:

az webapp config appsettings set --name <app_name> --resource-group <group_name> --settings WEBSITE_AUTH_PRESERVE_URL_FRAGMENT="true"

ユーザー要求へのアクセスAccess user claims

App Service では、特殊なヘッダーを使用して、アプリケーションにユーザー要求を渡します。App Service passes user claims to your application by using special headers. 外部要求ではこれらのヘッダーの設定が許可されないので、これらのヘッダーは App Service によって設定されている場合にのみ存在します。External requests aren't allowed to set these headers, so they are present only if set by App Service. いくつかのヘッダーの例は次のとおりです。Some example headers include:


任意の言語またはフレームワークで記述されたコードで、これらのヘッダーから必要な情報を取得できます。Code that is written in any language or framework can get the information that it needs from these headers. ASP.NET 4.6 アプリの場合は、 ClaimsPrincipal が自動的に適切な値に設定されます。For ASP.NET 4.6 apps, the ClaimsPrincipal is automatically set with the appropriate values. ただし、ASP.NET Core では、App Service のユーザー要求と統合する認証ミドルウェアが提供されません。ASP.NET Core, however, doesn't provide an authentication middleware that integrates with App Service user claims. 回避策については、「MaximeRouiller.Azure.AppService.EasyAuth」を参照してください。For a workaround, see MaximeRouiller.Azure.AppService.EasyAuth.

アプリケーションでは、/.auth/me を呼び出して認証されたユーザーの追加の詳細を取得することもできます。Your application can also obtain additional details on the authenticated user by calling /.auth/me. Mobile Apps サーバー SDK には、このデータを操作するためのヘルパー メソッドが用意されています。The Mobile Apps server SDKs provide helper methods to work with this data. 詳細については、「Azure Mobile Apps Node.js SDK の使用方法」と「Azure Mobile Apps 用 .NET バックエンド サーバー SDK の操作」を参照してください。For more information, see How to use the Azure Mobile Apps Node.js SDK, and Work with the .NET backend server SDK for Azure Mobile Apps.

アプリ コードでのトークンの取得Retrieve tokens in app code

サーバー コードからプロバイダー固有のトークンが要求ヘッダーに挿入されるので、これらのトークンに簡単にアクセスできます。From your server code, the provider-specific tokens are injected into the request header, so you can easily access them. 次の表は、可能なトークン ヘッダー名を示しています。The following table shows possible token header names:

プロバイダーProvider ヘッダー名Header names
Azure Active DirectoryAzure Active Directory X-MS-TOKEN-AAD-ID-TOKEN
Facebook トークンFacebook Token X-MS-TOKEN-FACEBOOK-ACCESS-TOKEN

クライアント コード (モバイル アプリやブラウザー内の JavaScript など) から、HTTP GET 要求を /.auth/me に送信します。From your client code (such as a mobile app or in-browser JavaScript), send an HTTP GET request to /.auth/me. 返される JSON にはプロバイダー固有のトークンがあります。The returned JSON has the provider-specific tokens.


アクセス トークンはプロバイダー リソースへのアクセス用であるため、クライアント シークレットを使用してプロバイダーを構成する場合にのみ存在します。Access tokens are for accessing provider resources, so they are present only if you configure your provider with a client secret. 更新トークンを取得する方法を確認するには、「更新アクセス トークン」を参照してください。To see how to get refresh tokens, see Refresh access tokens.

ID プロバイダー トークンの更新Refresh identity provider tokens

プロバイダーのアクセス トークン (セッション トークンではなく) が期限切れになった場合は、そのトークンを再度使用する前に、ユーザーを再認証する必要があります。When your provider's access token (not the session token) expires, you need to reauthenticate the user before you use that token again. アプリケーションの /.auth/refresh エンドポイントに GET 呼び出しを行って、トークンの期限切れを回避することができます。You can avoid token expiration by making a GET call to the /.auth/refresh endpoint of your application. 呼び出されると、App Service は認証されたユーザーのトークン ストア内のアクセス トークンを自動的に更新します。When called, App Service automatically refreshes the access tokens in the token store for the authenticated user. アプリ コードによる後続のトークン要求で、更新トークンを取得します。Subsequent requests for tokens by your app code get the refreshed tokens. ただし、トークンの更新が動作するためには、トークン ストアにプロバイダーの更新トークンが含まれている必要があります。However, for token refresh to work, the token store must contain refresh tokens for your provider. 更新トークンの取得方法は各プロバイダーによって文書化されていますが、次の一覧に概要を示します。The way to get refresh tokens are documented by each provider, but the following list is a brief summary:

  • Google: access_type=offline クエリ文字列パラメーターを /.auth/login/google API 呼び出しに追加します。Google: Append an access_type=offline query string parameter to your /.auth/login/google API call. Mobile Apps SDK を使用している場合は、LogicAsync オーバーロードの 1 つにパラメーターを追加できます (Google 更新トークンに関するページをご覧ください)。If using the Mobile Apps SDK, you can add the parameter to one of the LogicAsync overloads (see Google Refresh Tokens).
  • Facebook: 更新トークンを提供しません。Facebook: Doesn't provide refresh tokens. 長期間維持されるトークンの有効期限は 60 日間です (Facebook のアクセス トークンの有効期限と延長に関するページをご覧ください)。Long-lived tokens expire in 60 days (see Facebook Expiration and Extension of Access Tokens).
  • Twitter: アクセス トークンに有効期限はありません (Twitter OAuth の FAQ に関するページを参照してください)。Twitter: Access tokens don't expire (see Twitter OAuth FAQ).
  • Microsoft アカウント: Microsoft アカウント認証設定を構成する場合は、wl.offline_access スコープを選択します。Microsoft Account: When configuring Microsoft Account Authentication Settings, select the wl.offline_access scope.
  • Azure Active Directory: で、次の手順を実行します。Azure Active Directory: In, do the following steps:
    1. ページの上部にある [Read/Write] を選択します。At the top of the page, select Read/Write.

    2. 左側のブラウザーで、subscriptions > <subscription_name > resourceGroups > <resource_group_name> > providers > Microsoft.Web > sites > <app_name> > config > authsettings に移動します。In the left browser, navigate to subscriptions > <subscription_name > resourceGroups > <resource_group_name> > providers > Microsoft.Web > sites > <app_name> > config > authsettings.

    3. [編集] をクリックします。Click Edit.

    4. 次のプロパティを変更します。Modify the following property. <app_id> を、アクセスするサービスの Azure Active Directory アプリケーション ID に置き換えます。Replace <app_id> with the Azure Active Directory application ID of the service you want to access.

      "additionalLoginParams": ["response_type=code id_token", "resource=<app_id>"]
    5. [Put] をクリックします。Click Put.

プロバイダーが構成されたら、トークン ストアで更新トークンを見つけ、そのアクセス トークンの有効期限を確認できます。Once your provider is configured, you can find the refresh token and the expiration time for the access token in the token store.

任意の時点でアクセス トークンを更新するには、任意の言語で /.auth/refresh を呼び出します。To refresh your access token at any time, just call /.auth/refresh in any language. 次のスニペットでは、jQuery を使用して、JavaScript クライアントからアクセス トークンを更新します。The following snippet uses jQuery to refresh your access tokens from a JavaScript client.

function refreshTokens() {
  let refreshUrl = "/.auth/refresh";
  $.ajax(refreshUrl) .done(function() {
    console.log("Token refresh completed successfully.");
  }) .fail(function() {
    console.log("Token refresh failed. See application logs for details.");

ユーザーがアプリに許可されている権限を取り消すと、/.auth/me の呼び出しは 403 Forbidden 応答で失敗する可能性があります。If a user revokes the permissions granted to your app, your call to /.auth/me may fail with a 403 Forbidden response. エラーを診断するには、アプリケーション ログで詳細を確認します。To diagnose errors, check your application logs for details.

セッション トークンの有効期限の猶予期間の延長Extend session token expiration grace period

認証されたセッションは、8 時間後に期限切れになります。The authenticated session expires after 8 hours. 認証されたセッションの期限が切れた後、既定で 72 時間の猶予期間があります。After an authenticated session expires, there is a 72-hour grace period by default. この猶予期間内は、ユーザーを再認証せずにセッション トークンを App Service で更新できます。Within this grace period, you're allowed to refresh the session token with App Service without reauthenticating the user. セッション トークンが無効になったときに /.auth/refresh を呼び出すことができ、トークンの有効期限を自分で追跡する必要はありません。You can just call /.auth/refresh when your session token becomes invalid, and you don't need to track token expiration yourself. 72 時間の猶予期間が経過した後、ユーザーはもう一度サインインして有効なセッション トークンを取得する必要があります。Once the 72-hour grace period is lapses, the user must sign in again to get a valid session token.

72 時間が十分な時間でない場合は、この有効期間を延長することができます。If 72 hours isn't enough time for you, you can extend this expiration window. 有効期限を長期に延長すると、セキュリティに大きく影響する可能性があります (認証トークンが漏洩または盗難にあった場合など)。Extending the expiration over a long period could have significant security implications (such as when an authentication token is leaked or stolen). したがって、既定の 72 時間のままにするか、延長期間を最小限の値に設定する必要があります。So you should leave it at the default 72 hours or set the extension period to the smallest value.

既定の有効期間を延長するには、Cloud Shell で次のコマンドを実行します。To extend the default expiration window, run the following command in the Cloud Shell.

az webapp auth update --resource-group <group_name> --name <app_name> --token-refresh-extension-hours <hours>


猶予期間は、ID プロバイダーからのトークンではなく、App Service で認証されたセッションにのみ適用されます。The grace period only applies to the App Service authenticated session, not the tokens from the identity providers. 有効期限が切れたプロバイダー トークンの猶予期間はありません。There is no grace period for the expired provider tokens.

サインイン アカウントのドメインの制限Limit the domain of sign-in accounts

Microsoft アカウントと Azure Active Directory の両方に複数のドメインからサインインできます。Both Microsoft Account and Azure Active Directory lets you sign in from multiple domains. たとえば、Microsoft アカウントでは アカウントが許可されます。For example, Microsoft Account allows,, and accounts. Azure AD では、サインイン アカウントに任意の数のカスタム ドメインが許可されます。Azure AD allows any number of custom domains for the sign-in accounts. ただし、ユーザーを独自のブランドの Azure AD サインインページ (contoso.comなど) に直接誘導することもできます。However, you may want to accelerate your users straight to your own branded Azure AD sign-in page (such as サインイン アカウントのドメイン名を提示するには、以下の手順に従います。To suggest the domain name of the sign-in accounts, follow these steps. で、subscriptions > < subscription_ name > resourceGroups > < resource_ group_ name> > providers > Microsoft.Web > sites > < app_ name> > config > authsettings に移動します。In, navigate to subscriptions > <subscription_name > resourceGroups > <resource_group_name> > providers > Microsoft.Web > sites > <app_name> > config > authsettings.

[Edit] をクリックし、次のプロパティを変更し、 [Put] をクリックします。Click Edit, modify the following property, and then click Put. <domain_name> は使用するドメインで置き換えてください。Be sure to replace <domain_name> with the domain you want.

"additionalLoginParams": ["domain_hint=<domain_name>"]

この設定で、domain_hint クエリ文字列パラメーターがログイン リダイレクト URL に追加されます。This setting appends the domain_hint query string parameter to the login redirect URL.


クライアントは、リダイレクト URL を受け取った後で domain_hint パラメーターを削除し、別のドメインでログインできます。It's possible for the client to remove the domain_hint parameter after receiving the redirect URL, and then login with a different domain. そのため、この機能は便利ですが、セキュリティ機能ではありません。So while this function is convenient, it's not a security feature.

ユーザーを承認または拒否するAuthorize or deny users

App Service は最も単純な承認ケース (つまり、認証されていない要求の拒否) を処理しますが、アプリでは、特定のユーザー グループだけにアクセスを制限するなど、よりきめ細かな承認動作が必要になる場合があります。While App Service takes care of the simplest authorization case (i.e. reject unauthenticated requests), your app may require more fine-grained authorization behavior, such as limiting access to only a specific group of users. 場合によっては、サインインしたユーザーに対してアクセスを許可または拒否するためのカスタム アプリケーション コードの記述が必要になります。In certain cases, you need to write custom application code to allow or deny access to the signed-in user. また、App Service やお使いの ID プロバイダーが、コードの変更を必要とせずにサポートできる場合もあります。In other cases, App Service or your identity provider may be able to help without requiring code changes.

サーバー レベル (Windows アプリのみ)Server level (Windows apps only)

Windows アプリでは、Web.config ファイルを編集して IIS Web サーバーの承認動作を定義できます。For any Windows app, you can define authorization behavior of the IIS web server, by editing the Web.config file. Linux アプリは、IIS を使用しないため、Web.config を使用して構成することはできません。Linux apps don't use IIS and can't be configured through Web.config.

  1. https://<app-name> に移動しますNavigate to https://<app-name>

  2. App Service ファイルのブラウザー エクスプローラーで、site/wwwroot に移動します。In the browser explorer of your App Service files, navigate to site/wwwroot. Web.config が存在しない場合は、 + > [新しいファイル] を選択して作成します。If a Web.config doesn't exist, create it by selecting + > New File.

  3. Web.config の鉛筆を選択して編集します。Select the pencil for Web.config to edit it. 次の構成コードを追加し、 [保存] をクリックします。Add the following configuration code and click Save. Web.config が既に存在する場合は、すべての内容を含めた <authorization> 要素を追加するだけです。If Web.config already exists, just add the <authorization> element with everything in it. 許可するアカウントを <allow> 要素に追加します。Add the accounts you want to allow in the <allow> element.

    <?xml version="1.0" encoding="utf-8"?>
            <allow users=","/>
            <deny users="*"/>

ID プロバイダー レベルIdentity provider level

ID プロバイダーによって特定のターンキー承認が提供される場合があります。The identity provider may provide certain turn-key authorization. 例:For example:

アプリケーション レベルApplication level

他のいずれのレベルでも必要な承認が提供されない場合、またはお使いのプラットフォームまたは ID プロバイダーがサポートされていない場合、ユーザーの要求に基づいてユーザーを承認するカスタム コードを記述する必要があります。If either of the other levels don't provide the authorization you need, or if your platform or identity provider isn't supported, you must write custom code to authorize users based on the user claims.

次の手順Next steps