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

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

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

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

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

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

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

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

4. [テナントの種類] で、従業員とビジネス ゲスト向けの [従業員の構成 (現在のテナント)] を選択するか、コンシューマーとビジネス顧客向けの [外部構成] を選択します。

アプリ登録の選択

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

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

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

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

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

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

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

• このアプリケーションからの要求のみを許可する
• 特定のクライアント アプリケーションからの要求を許可する
• すべてのアプリケーションからの要求を許可する (非推奨)

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

• すべての ID からの要求を許可する
• 特定の ID からの要求を許可する

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

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

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

認証設定を構成する

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

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

• 認証を必須にする
• 認証されていないアクセスを許可する

認証されていない要求の場合

• HTTP 302 リダイレクトが見つかりました: Web サイトに推奨
• HTTP 401 非認可: API に推奨
• HTTP 403 Forbidden
• HTTP 404 見つかりません

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

ID プロバイダーの追加

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

[追加] を選択します。

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

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

要求を承認する

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

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

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

{
    "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 アプリケーション設定は、着信トークンに oid クレームを含めることを要求するよう、"true" または "1" に構成できます。 allowedPrincipals.identities が構成されている場合、この設定は無視され、true として扱われます (oid クレームは、この指定された ID リストに対してチェックされるため)。

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

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

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

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

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

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

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 アプリ用に以前に作成したアプリの登録を選択します。 アプリ登録が表示されない場合は、user_impersonation スコープがアプリ登録に追加されていることを確認します。

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

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

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

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

1. ポータル メニューから [Microsoft Entra] を選択します。
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 での独自のアプリ登録を使用して構成します。
• App Service アプリごとに独自のアクセス許可と同意を付与します。
• デプロイ スロットごとに個別のアプリ登録を使用することで、環境間でアクセス許可を共有することを回避します。 新しいコードをテストするとき、このプラクティスは、問題が運用アプリに影響を与えることを回避する上で役立つことがあります。

Microsoft Graph に移行する

一部の古いアプリは、完全な廃止が予定されている非推奨の Azure AD Graph に依存するように設定されている場合もあります。 たとえば、ミドルウェア パイプラインの認可フィルターの一部としてグループ メンバーシップをチェックするために、アプリのコードで Azure AD Graph を呼び出していた可能性があります。 アプリでは、Azure AD Graph 廃止プロセスの一環として Microsoft Entra によって提供されるガイダンスに従って 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 によって提供されるガイダンスに従って更新する必要もあります。

次のステップ

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

• チュートリアル: Azure Storage と Microsoft Graph にアクセスする Web アプリでユーザーを認証および認可する
• チュートリアル:Azure App Service でユーザーをエンド ツー エンドで認証および承認する