Microsoft Entra サインインを使用するように App Service アプリまたは Azure Functions アプリを構成する

  • [アーティクル]

別の認証プロバイダーを選択すると、それにジャンプします。

この記事では、アプリで Microsoft ID プラットフォーム (Microsoft Entra ID) を認証プロバイダーとして使用してユーザーがサインインするように、Azure App Service または Azure Functions の認証を構成する方法について説明します。

App Service 認証機能では、Microsoft ID プラットフォームを使ってアプリの登録を自動的に作成できます。 また、ユーザーまたはディレクトリ管理者が個別に作成した登録を使用することもできます。

Note

新しい登録を自動的に作成するオプションは、政府機関向けクラウドや [顧客向けMicrosoft Entra ID (プレビュー)] を使用する場合には使用できません。 代わりに、 登録を個別に定義します。

オプション 1: 新しいアプリ登録を自動作成する

アプリ登録を別個に作成する必要がない限り、このオプションを使用してください。 Microsoft Entra ID でのアプリ登録は、作成後にカスタマイズできます。

  1. Azure portal にサインインし、アプリに移動します。

  2. 左側のメニューで [認証] を選択します。 [ID プロバイダーの追加] を選択します。

  3. [ID プロバイダー] ドロップダウンで [Microsoft] を選択します。 既定では、新しい登録を作成するオプションが選択されています。 登録の名前またはサポートされているアカウントの種類を変更できます。

    クライアント シークレットが作成され、MICROSOFT_PROVIDER_AUTHENTICATION_SECRET という名前のスロット固定のアプリケーション設定 として保存され ます。 Azure Key Vault でシークレットを管理する場合は、Key Vault 参照を使用するように、この設定を後で更新することができます。

  4. これがアプリケーション用に構成された最初の ID プロバイダーである場合は、「App Service 認証設定」のセクションも表示されます。 それ以外の場合は、次の手順に進むことができます。

    これらのオプションは、アプリケーションが認証されていない要求にどのように応答するかを決定し、既定の選択によって、この新しいプロバイダーにサインインするためのすべての要求がリダイレクトされます。 [認証設定] の横にある [編集] を選択すると、この動作をメインの [認証] 画面からカスタマイズすることができます。 これらのオプションの詳細については、「認証フロー」を参照してください。

  5. (省略可能) [次へ: アクセス許可] を選択し、アプリで必要な Microsoft Graph のアクセス許可を追加します。 これらはアプリの登録に追加されますが、後で変更することもできます。

  6. [追加] を選択します。

これで、アプリケーションで認証に Microsoft ID プラットフォームを使う準備ができました。 [認証] 画面にプロバイダーが一覧表示されます。 そこから、このプロバイダーの構成を編集または削除できます。

Azure Storage と Microsoft Graph にアクセスする Web アプリの Microsoft Entra サインインを構成する例については、こちらのチュートリアルを参照してください。

オプション 2: 個別に作成された既存の登録を使用する

既存のアプリ登録を使用するように App Service 認証を構成できます。 既存のアプリ登録を使用する最も一般的なケースは、次のとおりです。

  • お使いのアカウントに、Microsoft Entra テナントでアプリ登録を作成するためのアクセス許可がない。
  • アプリが属しているものとは異なる Microsoft Entra テナントにあるアプリ登録を使用する必要がある。
  • 新しい登録を作成するオプションは、政府機関向けクラウドでは使用できません。

手順 1: App Service アプリ用に Microsoft Entra ID でアプリ登録を作成する

アプリ登録の作成中、後で App Service アプリで認証を構成するときに必要になる次の情報を収集してください。

  • クライアント ID
  • テナント ID
  • クライアント シークレット (省略可能ですが、お勧めします)
  • アプリケーション ID URI

アプリ登録を作成する手順は、従業員テナントと顧客テナントのどちらを使用しているかによって異なります。 以下のタブを使用して、シナリオに適した一連の手順を選択します。

アプリを登録するには、次の手順に従います。

  1. Azure portal にサインインし、 [App Services] を探して選択してから、アプリを選択します。 アプリの URL をメモしておきます。 それを使用して、Microsoft Entra アプリ登録を構成します。

  2. ポータルでテナントに移動します。

    ポータル メニューから [Microsoft Entra ID] を選択します。 使用しているテナントが、App Service アプリケーションの構成に使用するものと異なる場合は、まずディレクトリを変更する必要があります。

  3. [概要] 画面で、テナント ID とプライマリ ドメインをメモします。

  4. 左側のナビゲーションで、[アプリの登録]>[新規登録] を選択します。

  5. [アプリケーションの登録] ページで、アプリの登録の [名前] を入力します。

  6. [サポートされているアカウントの種類] で、このアプリにアクセスできるアカウントの種類を選択します。

  7. [リダイレクト URI] セクションで、プラットフォームとして [Web] を選択し、「<app-url>/.auth/login/aad/callback」と入力します。 たとえば、「 https://contoso.azurewebsites.net/.auth/login/aad/callback 」のように入力します。

  8. [登録] を選択します。

  9. アプリの登録が作成されたら、後のために [アプリケーション (クライアント) ID] と [ディレクトリ (テナント) ID] をコピーします。

  10. 左側のナビゲーションで [Authentication] を選択します。 [Implicit grant and hybrid flows](暗黙的な許可とハイブリッド フロー) で [ID トークン] を有効にして、App Service からの OpenID Connect ユーザーのサインインを許可します。 [保存] を選択します。

  11. (省略可能) 左側のナビゲーションで、[ブランド化とプロパティ] を選択します。 [ホーム ページ URL] に App Service アプリの URL を入力し、 [保存] を選択します。

  12. 左側のナビゲーションで、[API の公開]>[追加]>[保存] を選択します。 この値によって、リソースとして使用される際にアプリケーションを一意に識別し、アクセスを許可するトークンを要求することが可能になります。 作成するスコープのプレフィックスとして使用されます。

    シングルテナント アプリの場合、api://<application-client-id> 形式である既定値を使用できます。 テナントの検証済みドメインの 1 つに基づき、https://contoso.com/api のような、もっと読みやすい URI を指定することもできます。 マルチテナントのアプリの場合は、カスタム URI を指定する必要があります。 アプリ ID URI で使用できる形式の詳細については、アプリ登録のベスト プラクティス リファレンス ページを参照してください。

  13. [Scope の追加] を選択します。

    1. [スコープ名] に、「user_impersonation」と入力します。
    2. [同意できるユーザー] で、ユーザーがこのスコープに同意できるようにする場合は、[管理者とユーザー] を選択します。
    3. 同意ページでユーザーに表示する同意スコープの名前と説明をテキスト ボックスに入力します。 たとえば、「 <アプリケーション名> にアクセスする」と入力します。
    4. [スコープの追加] を選択します。

  14. (オプショナル) クライアント シークレットを作成するには、次の手順に従います。

    1. 左側のナビゲーションで、[証明書とシークレット]>[クライアント シークレット]>[新しいクライアント シークレット] を選択します。
    2. 説明と有効期限を入力し、 [追加] を選びます
    3. [値] フィールドで、クライアント シークレットの値をコピーします。 このページから移動すると、再び表示されることはありません。

  15. (オプショナル) 複数の応答 URL を追加するには、 [認証] を選択します。

  16. アプリの登録の設定を完了します。

    従業員テナントにその他の手順は必要ありません。

手順 2: App Service アプリで Microsoft Entra ID を有効にする

  1. Azure portal にサインインし、アプリに移動します。

  2. 左側のナビゲーションで、[認証]>[ID プロバイダーの追加]>[Microsoft] を選択します。

  3. 作成したアプリの登録の [テナントの種類] を選択します。

  4. 適切なテナントの種類の手順を使用して、作成した登録を使用するようにアプリを構成します。

    [アプリの登録の種類] で、次のいずれかを選択します。

    • このディレクトリ内の既存アプリの登録を選択: 現在のテナントからアプリ登録を選択し、必要なアプリ情報を自動的に収集します。 システムでは、アプリの登録に対して新しいクライアント シークレットを作成して、それを使用するようにアプリを自動的に構成しようとします。 既定の発行者の URL は、アプリの登録で構成されているサポート対象のアカウントの種類に基づいて設定されます。 この既定値を変更する場合は、次の表を参照してください。
    • 既存アプリの登録の詳細を提供します: 現在のテナントで登録のクエリを実行するアクセス許可がアカウントにない場合、または別のテナントにあるアプリ登録の場合に詳細を指定します。 このオプションでは、次の表に従って構成値を手動で入力する必要があります。

    従業員テナントの認証エンドポイントは、クラウド環境に固有の値である必要があります。 たとえば、グローバル Azure の従業員テナントでは、"https://login.microsoftonline.com" を認証エンドポイントとして使用します。 適切な発行者の URL を作成するために必要であるため、認証エンドポイントの値をメモします。

    構成の詳細を直接入力する場合は、アプリの登録の作成プロセス中に収集した値を使用します。

    フィールド 説明
    アプリケーション (クライアント) ID アプリの登録のアプリケーション (クライアント) ID を使用します。
    クライアント シークレット アプリの登録で生成したクライアント シークレットを使用します。 クライアント シークレットを使用すると、ハイブリッド フローが使用され、App Service によってアクセス トークンと更新トークンが返されます。 クライアント シークレットが設定されていない場合は、暗黙的なフローが使用され、ID トークンのみが返されます。 これらのトークンはプロバイダーによって送信され、App Service 認証トークン ストアに格納されます。
    発行者の URL <authentication-endpoint>/<tenant-id>/v2.0 を使用し、<authentication-endpoint> を、前の手順で決定したテナントの種類とクラウド環境の認証エンドポイントに置き換え、さらに、<tenant-id> を、アプリの登録が作成されたディレクトリ (テナント) ID に置き換えます。 Azure AD v1 を使用するアプリケーションの場合は、URL で /v2.0 を省略します。

    この値は、ユーザーを正しい Microsoft Entra テナントにリダイレクトするため、および適切なメタデータをダウンロードして、適切なトークン署名キーやトークン発行者のクレーム値などを特定するために使用されます。 テナント固有のエンドポイント以外の構成は、マルチテナントとして扱われます。 マルチテナント構成では、発行者またはテナント ID の検証はシステムによって実行されません。これらの検査は、アプリの認可ロジックで完全に処理する必要があります。
    許可されるトークン対象ユーザー このフィールドは省略可能です。 構成された [アプリケーション (クライアント) ID] は、"常に" 許可された対象ユーザーであると暗黙的に見なされます。 アプリケーションが他のクライアントによって呼び出される API を表している場合は、アプリの登録で構成したアプリケーション ID URI も追加する必要があります。 許可された対象ユーザーの一覧全体で合計 500 文字の制限があります。

    クライアント シークレットが、MICROSOFT_PROVIDER_AUTHENTICATION_SECRET という名前のスロット固定のアプリケーション設定 として保存され ます。 Azure Key Vault でシークレットを管理する場合は、Key Vault 参照を使用するように、この設定を後で更新することができます。

  5. これがアプリケーション用に構成された最初の ID プロバイダーである場合は、「App Service 認証設定」のセクションも表示されます。 それ以外の場合は、次の手順に進むことができます。

    これらのオプションは、アプリケーションが認証されていない要求にどのように応答するかを決定し、既定の選択によって、この新しいプロバイダーにサインインするためのすべての要求がリダイレクトされます。 [認証設定] の横にある [編集] を選択すると、この動作をメインの [認証] 画面からカスタマイズすることができます。 これらのオプションの詳細については、「認証フロー」を参照してください。

  6. [追加] を選択します。

これで、アプリケーションで認証に Microsoft ID プラットフォームを使う準備ができました。 [認証] 画面にプロバイダーが一覧表示されます。 そこから、このプロバイダーの構成を編集または削除できます。

要求を承認する

既定では、App Service 認証は、認証のみを処理し、呼び出し元が本人であるかどうかを判断します。 認可は、その呼び出し元が何らかのリソースにアクセスできる必要があるかどうかを判断するものであり、認証の範囲を超えた追加の手順です。 これらの概念の詳細については、Microsoft ID プラットフォームの承認の基本に関する記事を参照してください。

アプリは、コード内で認可の決定を行うことができます。 App Service 認証では、役に立つ組み込みチェックが提供されていますが、それだけではアプリの認可ニーズをカバーするのに十分ではない場合があります。

ヒント

マルチテナント アプリケーションでは、このプロセスの一環として要求の発行者とテナント ID を検証して、値が許可されていることを確認する必要があります。 App Service 認証がマルチテナント シナリオ用に構成されている場合、要求元のテナントは検証されません。 たとえば、組織がサービスにサインアップしているかどうかに基づいて、アプリを特定のテナントに制限する必要がある場合があります。 Microsoft ID プラットフォームのマルチテナント ガイダンスを参照してください。

アプリケーション コードから検証を実行する

アプリ コードで認可チェックを実行すると、App Service 認証によって利用可能になるクレーム情報を活用できます。 挿入された x-ms-client-principal ヘッダーには、呼び出し元に関してアサートされたクレームを含む Base64 でエンコードされた JSON オブジェクトが含まれています。 既定では、これらのクレームはクレーム マッピングを経由するため、クレーム名がトークンに表示されるものと常に一致するとは限りません。 たとえば、tid クレームは代わりに http://schemas.microsoft.com/identity/claims/tenantid にマップされます。

また、挿入された x-ms-token-aad-access-token ヘッダーから基になるアクセス トークンを直接操作することもできます。

組み込み認可ポリシーを使用する

作成されたアプリ登録では、Microsoft Entra テナントにおける受信要求を認証します。 また、既定では、テナント内のだれでもアプリにアクセスできるようにします。これは、多くのアプリにとって問題ありません。 ただし、一部のアプリケーションでは、承認の決定を行い、アクセスをさらに制限する必要があります。 多くの場合、アプリケーション コードはカスタム承認ロジックを処理するのに最適な場所です。 ただし、一般的なシナリオについては、Microsoft ID プラットフォームに、アクセスを制限するために使用できる組み込みのチェックが用意されています。

このセクションでは、App Service authentication V2 API を使用して組み込みチェックを有効にする方法について説明します。 現時点では、これらの組み込みチェックを構成する唯一の方法は、Azure Resource Manager テンプレートまたは REST API を使用することです。

API オブジェクト内では、Microsoft Entra ID プロバイダーの構成には、次の構造のように defaultAuthorizationPolicy オブジェクトを含めることができる validation セクションがあります。

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
プロパティ 説明
defaultAuthorizationPolicy アプリにアクセスするために満たす必要がある要件のグループ。 アクセスは、構成された各プロパティに対する論理 AND に基づいて許可されます。 allowedApplications と allowedPrincipals の両方が構成されている場合、着信要求が受け入れられるためには、両方の要件を満たす必要があります。
allowedApplications アプリを呼び出しているクライアント リソースを表す文字列アプリケーション クライアント ID の許可リスト。 このプロパティが空でない配列として構成されている場合、リストで指定されたアプリケーションによって取得されたトークンのみが受け入れられます。

このポリシーは、受信トークン (アクセス トークンである必要があります) の appid または azp クレームを評価します。 Microsoft ID プラットフォーム クレームのリファレンスに関するページを参照してください。
allowedPrincipals 着信要求によって表されるプリンシパルがアプリにアクセスできるかどうかを判断するチェックのグループ。 allowedPrincipals の充足は、構成されたプロパティに対する論理 OR に基づいています。
identities (allowedPrincipalsで) アクセス権を持つユーザーまたはアプリケーションを表す文字列オブジェクト ID の許可リスト。 このプロパティが空でない配列として構成されている場合、要求によって表されるユーザーまたはアプリケーションがリストで指定されていれば、allowedPrincipals の要件を満たすことができます。 ID の一覧全体で合計 500 文字の制限があります。

このポリシーは、受信トークンの oid クレームを評価します。 Microsoft ID プラットフォーム クレームのリファレンスに関するページを参照してください。

また、一部のチェックは、使用されている API バージョンに関係なく、アプリケーション設定を通じて構成できます。 WEBSITE_AUTH_AAD_ALLOWED_TENANTS アプリケーション設定は、受信トークンが tid クレームで指定されたテナントのものであることを要求するよう、最大 10 個のテナント ID のコンマ区切りリスト (例: "559a2f9c-c6f2-4d31-b8d6-5ad1a13f8330,5693f64a-3ad5-4be7-b846-e9d1141bcebc") を使用して構成できます。 WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL アプリケーション設定は、着信トークンに oid クレームを含めることを要求するよう、"true" または "1" に構成できます。 allowedPrincipals.identities が構成されている場合、この設定は無視され、true として扱われます (oid クレームは、この指定された ID リストに対してチェックされるため)。

これらの組み込みチェックに失敗した要求には、HTTP 403 Forbidden 応答が渡されます。

App Service にアクセスするようにクライアント アプリを構成する

前のセクションでは、ユーザーを認証するために App Service または Azure 関数を登録しました。 このセクションでは、N 層アーキテクチャなどにおいて、Microsoft Entra ID でネイティブ クライアントまたはデーモン アプリを登録して、ユーザーまたはそれらのために App Service によって公開される API へのアクセスを要求できるようにする方法を説明します。 ユーザーを認証するだけの場合は、このセクションの手順を完了する必要はありません。

ネイティブ クライアント アプリケーション

サインインしているユーザーの代わりに App Service アプリの API へのアクセスを要求するようにネイティブ クライアントを登録できます。

  1. ポータル メニューから [Microsoft Entra ID] を選択します。

  2. 左側のナビゲーションで、[アプリの登録]>[新規登録] を選択します。

  3. [アプリケーションの登録] ページで、アプリの登録の [名前] を入力します。

  4. [リダイレクト URI] で、[パブリック クライアント (モバイルとデスクトップ)] を選択し、URL「<app-url>/.auth/login/aad/callback」を入力します。 たとえば、https://contoso.azurewebsites.net/.auth/login/aad/callback のようにします。

  5. [登録] を選択します。

  6. アプリの登録が作成されたら、 [アプリケーション (クライアント) ID] の値をコピーします。

    Note

    Microsoft Store アプリケーションの場合は、代わりにパッケージ SID を URI として使用します。

  7. 左側のナビゲージョンで、[API のアクセス許可]>[アクセス許可の追加]>[自分の API] を選択します。

  8. App Service アプリ用に以前に作成したアプリの登録を選択します。 アプリの登録が表示されない場合は、「App Service アプリ用に Microsoft Entra ID でアプリ登録を作成する」で user_impersonation スコープを追加したことを確認します。

  9. [委任されたアクセス許可] で、 [user_impersonation] を選択し、 [アクセス許可の追加] を選択します。

これで、ユーザーに代わって App Service アプリにアクセスを要求できるネイティブ クライアント アプリケーションが構成されました。

デーモン クライアント アプリケーション (サービス ツー サービスのコール)

N 層アーキテクチャでクライアント アプリは、(ユーザーのためにではなく) クライアント アプリ自体のために App Service または関数アプリを呼び出すトークンを取得できます。 このシナリオは、ログイン ユーザーなしでタスクを実行する非対話型デーモン アプリケーションに役立ちます。 これには標準の OAuth 2.0 クライアント資格情報の付与が使用されます。

  1. ポータル メニューから [Microsoft Entra ID] を選択します。
  2. 左側のナビゲーションで、[アプリの登録]>[新規登録] を選択します。
  3. [アプリケーションの登録] ページで、アプリの登録の [名前] を入力します。
  4. デーモン アプリケーションの場合、リダイレクト URI は不要であるため、空のままでかまいません。
  5. [登録] を選択します。
  6. アプリの登録が作成されたら、 [アプリケーション (クライアント) ID] の値をコピーします。
  7. 左側のナビゲーションで、[証明書とシークレット]>[クライアント シークレット]>[新しいクライアント シークレット] を選択します。
  8. 説明と有効期限を入力し、 [追加] を選びます
  9. [値] フィールドで、クライアント シークレットの値をコピーします。 このページから移動すると、再び表示されることはありません。

これで、resource パラメーターをターゲット アプリのアプリケーション ID URI に設定することで、クライアント ID とクライアント シークレットを使用してアクセス トークンを要求できます。 その後、標準の OAuth 2.0 Authorization ヘッダーを使用して、得られたアクセス トークンをターゲット アプリに提示できます。また、App Service の認証によって、通常通りにトークンが検証および使用され、呼び出し元 (この場合はユーザーではなくアプリである) が認証されたことが示されます。

現時点で、これによって Microsoft Entra テナント内の "すべて" のクライアント アプリケーションがアクセス トークンを要求し、ターゲット アプリに対して認証を行うことができます。 また、"承認" を実施して特定のクライアント アプリケーションのみを許可する場合は、追加の構成を行う必要があります。

  1. 保護する App Service または関数アプリを表すアプリ登録のマニフェストで、アプリ ロールを定義します。
  2. 承認する必要があるクライアントを表すアプリの登録で、 [API のアクセス許可]>[アクセス許可の追加]>[自分の API] を選択します。
  3. 前に作成したアプリの登録を選択します。 アプリの登録が表示されない場合は、アプリ ロールを追加したことを確認してください。
  4. [アプリケーションのアクセス許可] で、前に作成したアプリ ロールを選択し、 [アクセス許可の追加] を選択します。
  5. クライアント アプリケーションがアクセス許可を要求することを承認するために、必ず [管理者の同意を与える] を選択してください。
  6. (ロールを追加する前の) 前述のシナリオと同様に、これで、同じターゲット resource のアクセス トークンを要求できます。アクセス トークンには、クライアント アプリケーションのために承認されたアプリ ロールを含む roles 要求が含まれます。
  7. これで、ターゲット App Service または関数アプリのコード内で、必要なロールがトークンに存在しているか検証できます (これは App Service 認証では実行されません)。 詳しくは、「ユーザー要求へのアクセス」をご覧ください。

これで、独自の ID を使用して App Service アプリにアクセスできるデーモン クライアント アプリケーションが構成されました。

ベスト プラクティス

認証の設定に使用する構成に関係なく、次のベスト プラクティスによってテナントとアプリケーションのセキュリティが強化されます。

  • 各 App Service アプリを、Microsoft Entra ID での独自のアプリ登録を使用して構成します。
  • App Service アプリごとに独自のアクセス許可と同意を付与します。
  • デプロイ スロットごとに個別のアプリ登録を使用することで、環境間でアクセス許可を共有することを回避します。 新しいコードをテストするとき、このプラクティスは、問題が運用アプリに影響を与えることを回避する上で役立つことがあります。

Microsoft Graph に移行する

一部の古いアプリは、完全な廃止が予定されている非推奨の Azure AD Graph に依存するように設定されている場合もあります。 たとえば、ミドルウェア パイプラインの認可フィルターの一部としてグループ メンバーシップをチェックするために、アプリのコードで Azure AD Graph を呼び出していた可能性があります。 アプリでは、Azure AD Graph 廃止プロセスの一環として Microsoft Entra ID によって提供されるガイダンスに従って Microsoft Graph に移行する必要があります。 これらの手順に従うにあたって、App Service 認証の構成を変更することが必要な場合があります。 アプリの登録に Microsoft Graph のアクセス許可を追加すると、次のことができます。

  1. "/v2.0" サフィックスが含まれるように発行者 URL をまだ更新していない場合、更新します。

  2. サインイン構成から Azure AD Graph アクセス許可の要求を削除します。 変更するプロパティは、使用している管理 API のバージョンによって異なります。

    • V1 API (/authsettings) を使用している場合、これは additionalLoginParams 配列内にあります。
    • V2 API (/authsettingsV2) を使用している場合、これは loginParameters 配列内にあります。

    たとえば、"https://graph.windows.net" への参照を削除する必要があります。 これには、("/v2.0" エンドポイントでサポートされていない) resource パラメーター、または明示的に要求している Azure AD Graph からのスコープが含まれます。

    また、アプリケーション登録用に設定した新しい Microsoft Graph アクセス許可を要求するように構成を更新する必要もあります。 多くの場合、.default スコープを使用してこの設定を簡略化できます。 これを行うには、新しいサインイン パラメーター scope=openid profile email https://graph.microsoft.com/.default を追加します。

これらの変更により、App Service 認証でサインインしようとすると、Azure AD Graph へのアクセス許可は要求されなくなり、代わりに Microsoft Graph のトークンが取得されます。 アプリケーション コードからそのトークンを使用する場合は、Microsoft Entra ID によって提供されるガイダンスに従って更新する必要もあります。

次のステップ