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

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

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

アプリケーションとそのユーザーのテナントを選択する

アプリケーションでユーザーをサインインさせる前に、従業員テナントまたは外部テナントに登録する必要があります。 従業員またはビジネス ゲストがアプリを使用できるようにするには、従業員テナントにアプリを登録します。 アプリがコンシューマーとビジネス ユーザー向けである場合は、外部テナントに登録します。

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

2. アプリの左側のメニューで [設定]>[認証] を選び、[ID プロバイダーの追加] を選びます。

3. [ID プロバイダーの追加] ページで、ID プロバイダーの値として Microsoft を選択して、Microsoft と Microsoft Entra の ID にサインインするためのプロバイダーを設定します。

4. [ アプリケーションとそのユーザーのテナントの選択] で、次のいずれかを選択します。

   • 従業員とビジネス ゲストの従業員構成 (現在のテナント)
   • コンシューマーとビジネスのお客様向けの外部構成

アプリ登録の選択

App Service 認証機能を使用すると、自動的にアプリ登録を作成できます。 または、自分またはディレクトリ管理者が個別に作成する登録を使用できます。

アプリ登録を個別に作成する必要がない限り、新しいアプリ登録を自動的に作成します。 必要に応じて、Microsoft Entra 管理センターでアプリ登録を後でカスタマイズできます。

既存のアプリ登録を使用する最も一般的なケースは、次のとおりです。

• お使いのアカウントに、Microsoft Entra テナントでアプリ登録を作成するためのアクセス許可がない。
• アプリを含むテナントとは異なる Microsoft Entra テナントのアプリ登録を使用する必要があります。 これは、テナントを選択したときに [外部構成] を選択した場合に常に当てはまる場合です。
• 新しい登録を作成するオプションは、政府機関向けクラウドでは使用できません。

追加のチェックを構成する

"追加のチェック" により、どの要求にアプリケーションへのアクセスを許可するかが決まります。 この動作を今すぐカスタマイズすることも、認証設定の横にある [編集] を選択して、後でメインの [認証] ページからこれらの設定を調整することもできます。

クライアント アプリケーション要件について、次を行うかどうかを選択します。

• このアプリケーション自体からの要求のみを許可します。
• 特定のクライアント アプリケーションからの要求を許可します。
• 任意のアプリケーションからの要求を許可します (推奨されません)。

ID 要件について、次を行うかどうかを選択します。

• 任意の ID からの要求を許可します。
• 特定の ID からの要求を許可します。

テナント要件について、次を行うかどうかを選択します。

• 発行者テナントからの要求のみを許可します。
• 特定のテナントからの要求を許可します。
• 発行者に基づく既定の制限を使用します。

アプリは、認可に関するその他の決定をコードで行うことが必要になる場合があります。 詳細については、この記事 の後半の「組み込みの承認ポリシーを使用 する」を参照してください。

認証設定を構成する

認証設定は、認証されていない要求に対するアプリケーションの応答方法を決定します。 既定の選択では、この新しいプロバイダーでサインインするすべての要求がリダイレクトされます。 この動作を今すぐカスタマイズすることも、認証設定の横にある [編集] を選択して、後でメインの [認証] ページからこれらの設定を調整することもできます。 詳細については、「認証フロー」をご覧ください。

アクセスの制限について、次を行うかどうかを決定します。

• 認証が必要です。
• 認証されていないアクセスを許可します。

認証されていない要求の場合は、エラー オプションを選択します。

• HTTP 302 Found redirect: Web サイトに推奨
• HTTP 401 Unauthorized: API 用に推奨されています
• HTTP 403 Forbidden
• HTTP 404 Not found

[トークン ストア] を選択します (推奨)。 トークン ストアは、アプリケーションのトークンを収集、格納、更新します。 アプリにトークンが必要ない場合、またはパフォーマンスを最適化する必要がある場合は、後でこの動作を無効にすることができます。

ID プロバイダーの追加

ワークフォース構成を選択した場合は、[ 次へ: アクセス許可 ] を選択し、アプリケーションに必要な Microsoft Graph のアクセス許可を追加できます。 これらのアクセス許可はアプリの登録に追加されますが、後で変更することもできます。 外部の構成を選択した場合は、Microsoft Graph のアクセス許可を後から追加できます。

• [追加] を選択します。

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

Azure Storage と Microsoft Graph にアクセスする Web アプリの Microsoft Entra サインインを構成する例については、Web アプリにアプリの認証を追加するに関する記事を参照してください。

要求を承認する

既定では、App Service 認証は 認証のみを処理します。 これにより、呼び出し元が本人であるかどうかが判断されます。 "認可" は、その呼び出し元が何らかのリソースにアクセスできる必要があるかどうかを判断するものであり、認証の範囲を超えた手順です。 詳細については、「認可の基本」を参照してください。

アプリは、コード内で認可の決定を行うことができます。 App Service 認証には いくつかの組み込みチェックが用意されています。これは役に立ちますが、アプリの承認ニーズを満たすには不十分な場合があります。 以降のセクションでは、これらの機能について説明します。

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

アプリ コードで承認チェックを実行する場合は、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 認証 V2 API を使用して組み込みチェックを有効にする方法について説明します。 現時点では、これらの組み込みチェックを構成する唯一の方法は、Azure Resource Manager テンプレートまたは REST API を使用することです。

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

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}

また、使用している API のバージョンに関係なく、 アプリケーション設定を使用していくつかのチェックを構成することもできます。 WEBSITE_AUTH_AAD_ALLOWED_TENANTS アプリケーション設定は、最大 10 個のテナント ID (たとえば、aaaabbbb-0000-cccc-1111-dddd2222eeee) のコンマ区切りリストを使用して構成できます。 この設定では、tid クレームで指定されているように、指定したテナントのいずれかからの受信トークンであることを要求できます。

WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL アプリケーション設定をtrueまたは1に設定して、受信トークンにoid要求を含める必要があります。 allowedPrincipals.identities構成した場合、この設定は無視され、oid要求がこの指定された ID の一覧に対してチェックされるため、true として扱われます。

これらの組み込みチェックに失敗した要求は、HTTP 403 Forbidden 応答を受け取ります。

シークレットの代わりにマネージド ID を使用する (プレビュー)

アプリの登録用にクライアント シークレットを構成する代わりに、 マネージド ID (プレビュー) を信頼するようにアプリケーションを構成できます。 シークレットの代わりに ID を使用することは、シークレットを管理する必要がないことを意味します。 処理するシークレットの有効期限イベントがなく、そのシークレットを開示または漏洩する可能性に関連する同じレベルのリスクはありません。

この ID を使用すると、クライアント シークレットの代わりにクライアント アサーションとして使用できるフェデレーション ID 資格情報を作成できます。 この方法は、従業員の構成でのみ使用できます。 現在、組み込みの認証機能では、フェデレーション ID 資格情報がプレビューとしてサポートされています。

このセクションの手順を使用して、このパターンを使用するように App Service または Azure Functions リソースを構成できます。 ここでの手順では、サポートされているいずれかの方法を使用してアプリの登録を既に設定していること、およびシークレットが既に定義されていることを前提としています。

1. 以下の手順に従って、ユーザー割り当てマネージド ID リソースを作成します。

2. その ID を App Service または Azure Functions リソースに割り当てます。

   Von Bedeutung

   作成するユーザー割り当てマネージド ID は、この登録を通じて App Service または Azure Functions アプリケーションにのみ割り当てる必要があります。 ID を別のリソースに割り当てると、そのリソースにアプリ登録への不要なアクセス権が付与されます。

3. マネージド ID の オブジェクト ID と クライアント ID の値をメモします。 次の手順でフェデレーション ID 資格情報を作成するには、オブジェクト ID が必要です。 後の手順でマネージド ID のクライアント ID を使用します。

4. Microsoft Entra ID の 手順に従って、既存のアプリケーションでフェデレーション ID 資格情報を構成します。 これらの手順には、アプリケーション コードを更新するためのセクションも含まれています。このセクションはスキップできます。

5. という名前の新しいOVERRIDE_USE_MI_FIC_ASSERTION_CLIENTIDを追加します。 その値を、前の手順で取得したマネージド ID の クライアント ID 値に設定します。 アプリ登録のクライアント ID は使用しないでください。 このアプリケーション設定は必ずスロットスティッキーとしてマークしてください。

6. アプリ リソースの組み込みの認証設定で、 クライアント シークレット設定名 を OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID に設定します。

   Azure portal を使用してこの変更を行うには:

   1. App Service または Azure Functions リソースに戻り、[ 認証 ] タブを選択します。
   2. [ ID プロバイダー ] セクションで、 Microsoft エントリの [編集 ] 列のアイコンを選択します。
   3. [ ID プロバイダーの編集 ] ダイアログで、[ クライアント シークレット設定名 ] のドロップダウン リストを開き、 OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTIDを選択します。
   4. 保存 を選択します。

   REST API を使用してこの変更を行うには:

   • clientSecretSettingName プロパティを OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTIDに設定します。 このプロパティは properties>identityProviders>azureActiveDirectory>registration にあります。

7. アプリケーションが期待どおりに動作することを確認します。 新しいサインイン アクションを正常に実行できる必要があります。

マネージド ID を使用した動作に満足したら、既存のシークレットを削除します。

1. アプリ コードがアプリケーション設定に依存していないことを確認します。 その場合は、 指示に従ってアプリケーション コードを更新し、アクセス トークンを要求します。

2. 以前にシークレットを保持していたアプリケーション設定を削除します。 このアプリケーション設定の名前は、に設定する前のクライアント OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTIDの値です。

3. アプリの登録を含むテナントを使用して 、Microsoft Entra 管理センター にサインインします。 もう一度アプリの登録に移動します。

4. [ 証明書とシークレット] で、[ クライアント シークレット ] を選択し、クライアント シークレットを削除します。

これで、シークレットなしで Microsoft Entra ID 認証を使用するようにアプリが構成されました。

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

前のセクションでは、ユーザーを認証するために App Service または Azure Functions アプリを登録しました。 次のセクションでは、Microsoft Entra でネイティブ クライアントまたはデーモン アプリを登録する方法について説明します。 これらのクライアントまたはアプリは、ユーザーまたは自身に代わって App Service によって公開される API (N 層アーキテクチャなど) へのアクセスを要求できます。 ユーザーのみを認証する場合は、次のセクションの手順は必要ありません。

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

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

1. Azure portal のメニューで、 Microsoft Entra ID を選択します。

2. 左側のウィンドウで、[管理]>[アプリの登録]を選択します。 次に、[ 新しい登録] を選択します。

3. [ アプリケーションの登録 ] ウィンドウの [名前] に、アプリ登録の名前を入力します。

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

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

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

   注

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

7. 左側のウィンドウで、[ 管理>API アクセス許可] を選択します。 次に [アクセス許可の追加]>[自分の API] を選択します。

8. 前に App Service アプリ用に作成したアプリの登録を選択します。 アプリの登録が表示されない場合は、アプリの登録に user_impersonation スコープを必ず追加してください。

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

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

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

N 層アーキテクチャでは、クライアント アプリケーションは、ユーザーの代わりにではなく、クライアント アプリ自体の代わりに App Service または Azure Functions アプリを呼び出すトークンを取得できます。 このシナリオは、ログインユーザーなしでタスクを実行する非対話型デーモン アプリケーションに役立ちます。 これには標準の OAuth 2.0 クライアント資格情報の付与が使用されます。 詳しくは、「Microsoft ID プラットフォームと OAuth 2.0 クライアント資格情報フロー」をご覧ください。

1. Azure portal のメニューで、 Microsoft Entra ID を選択します。

2. 左側のウィンドウで、[管理]>[アプリの登録]を選択します。 次に、[ 新しい登録] を選択します。

3. [ アプリケーションの登録 ] ウィンドウの [名前] に、アプリ登録の名前を入力します。

4. デーモン アプリケーションの場合、リダイレクト URI は必要ないため、[ リダイレクト URI ] ボックスを空のままにすることができます。

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

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

7. 左側のウィンドウで、管理>証明書およびシークレットを選択します。 次に [クライアント シークレット]>[新しいクライアント シークレット] を選択します。

8. 説明と有効期限を入力し、[ 追加] を選択します。

9. [値] フィールドで、クライアント シークレットの値をコピーします。 このページから移動した後は、再び表示されません。

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

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

1. アプリ登録のマニフェストに、保護する App Service または Azure Functions アプリを表すアプリ ロールを定義します。

2. 承認する必要があるクライアントを表すアプリの登録で、[API のアクセス許可]>[アクセス許可の追加]>[自分の API] を選択します。

3. 前に作成したアプリの登録を選択します。 アプリの登録が表示されない場合は、 アプリ ロールを追加したことを確認してください。

4. [ アプリケーションのアクセス許可] で、前に作成したアプリ ロールを選択します。 [アクセス許可の追加] を選択します。

5. [ 管理者の同意を付与 する] を選択して、アクセス許可を要求するクライアント アプリケーションを承認します。

   前のシナリオ (ロールを追加する前) と同様に、同じターゲット リソースの アクセス トークンを要求 できるようになりました。 アクセス トークンには、クライアント アプリケーションに対して承認されたアプリ ロールを含む roles 要求が含まれます。

ターゲットの App Service または Azure Functions アプリ コード内で、トークンに期待されるロールがあることを検証できるようになりました。 App Service 認証では、この検証は実行されません。 詳しくは、「アプリ コードでユーザー クレームにアクセスする」をご覧ください。

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

ベスト プラクティス

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

• 各 App Service アプリを、Microsoft Entra での独自のアプリ登録を使用して構成します。
• App Service アプリごとに独自のアクセス許可と同意を付与します。
• 環境間でのアクセス許可の共有を避けます。 個別のデプロイ スロットに対して個別のアプリ登録を使用します。 新しいコードをテストする場合、この方法は、問題が運用アプリに影響するのを防ぐのに役立ちます。

Microsoft Graph に移行する

一部の古いアプリは 、Azure AD Graph に依存するように設定されている可能性があります。これは非推奨となり、完全な提供終了が予定されています。 たとえば、ミドルウェア パイプラインの認可フィルターの一部としてグループ メンバーシップをチェックするために、アプリのコードで Azure AD Graph を呼び出す可能性があります。 アプリは Microsoft Graph に移行する必要があります。 詳細については、「Azure AD Graph アプリを Microsoft Graph に移行する」を参照してください。

この移行中に、App Service 認証の構成を変更することが必要な場合があります。 アプリの登録に Microsoft Graph のアクセス許可を追加したら、次のことができます。

• サフィックスがまだ含まれていない場合は、/v2.0 値を更新します。

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

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

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

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

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

関連コンテンツ

• Azure App Service および Azure Functions での認証と承認
• チュートリアル: Azure App Service でエンド ツー エンドでユーザーを認証および承認する

• クイック スタート: Azure App Service で実行されている Web アプリにアプリ認証を追加する