次の方法で共有

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

  • [アーティクル]

Note

2024 年 6 月 1 日より、新しく作成されたすべての App Service アプリには、名前付け規則 <app-name>-<random-hash>.<region>.azurewebsites.net を使用して一意の既定のホスト名を生成するオプションがあります。 既存のアプリ名は変更されません。

例: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

詳細については、App Service リソースの一意の既定のホスト名に関するページを参照してください。

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

この記事では、アプリで 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 テナントにあるアプリ登録を使用する必要がある。
  • 新しい登録を作成するオプションは、政府機関向けクラウドでは使用できません。

新しいアプリ登録を作成して使用するか、個別に作成した既存の登録を使用します。

オプション 1: 新しいアプリ登録を作成して使用する

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

Note

新しい登録を自動的に作成するオプションは、政府機関向けクラウドでは使用できません。 代わりに、 登録を個別に定義します。

新しいアプリ登録の [名前] を入力します。

[サポートされているアカウントの種類] を選択します。

  • 現在のテナント - 単一テナント。 この組織のディレクトリ内のアカウントのみ。 ディレクトリ内のすべてのユーザー アカウントとゲスト アカウントが、アプリケーションまたは API を使用できます。 このオプションは、対象ユーザーが組織の内部ユーザーである場合に使用します。
  • 任意の Microsoft Entra ディレクトリ - マルチテナント。 任意の組織ディレクトリ内のアカウント。 Microsoft の職場または学校アカウントを持つすべてのユーザーが、このアプリケーションまたは API を使用できます。 これには、Office 365 を使用する学校や企業が含まれます。 対象者がビジネスまたは教育関係のお客様であり、マルチテナント機能を有効にする場合にこのオプションを使用します。
  • Microsoft Entra ディレクトリと個人用 Microsoft アカウント。 任意の組織ディレクトリ内のアカウントと個人用 Microsoft アカウント (Skype、Xbox など)。 職場または学校アカウントあるいは個人用 Microsoft アカウントを持つすべてのユーザーが、このアプリケーションまたは API を使用できます。 これには、Office 365 を使用する学校と企業、および Xbox や Skype などのサービスへのサインインに使用されている個人用アカウントが含まれます。 最も幅広い Microsoft ID のセットを対象として、マルチテナント機能を有効にする場合にこのオプションを使用します。
  • 個人用 Microsoft アカウントのみ。 Xbox や Skype などのサービスのサインインに使用する個人用アカウント。 さまざまな Microsoft ID を対象とする場合に、このオプションを使用します。

登録名またはサポートされているアカウントの種類は後で必要に応じて変更できます。

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

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

次のいずれか:

  • [このディレクトリ内の既存アプリの登録を選択] を選択し、ドロップダウンからアプリ登録を選択します。
  • [既存のアプリ登録に関する詳細を指定してください] を選択し、以下を指定します。
    • アプリケーション (クライアント) ID。
    • クライアント シークレット (推奨)。 トークンの要求時にアプリケーションが自身の ID を証明するために使用するシークレット値。 この値は、MICROSOFT_PROVIDER_AUTHENTICATION_SECRET という名前で、アプリの構成にスロット固定のアプリケーション設定として保存されます。 クライアント シークレットが設定されていない場合、サービスからのサインイン操作は OAuth 2.0 の暗黙的な許可フローを使用しますが、これは推奨されません*。
    • 発行者の URL。<authentication-endpoint>/<tenant-id>/v2.0 という形式です。 <authentication-endpoint> を、クラウド環境に固有の認証エンドポイント値に置き換えます。 たとえば、グローバル Azure の従業員テナントでは、"https://login.microsoftonline.com" を認証エンドポイントとして使用します。

従業員テナントでアプリ登録を手動で作成する必要がある場合は、アプリケーションの登録に関するクイックスタートに従ってください。 登録プロセスを進める際は、必ずアプリケーション (クライアント) ID とクライアント シークレットの値を書き留めます。

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

作成後、アプリ登録を変更します。

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

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

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

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

  3. (推奨) クライアント シークレットを作成するには、次の手順に従います。

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

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

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

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

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

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

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 認証では、役に立つ組み込みチェックが提供されていますが、それだけではアプリの認可ニーズをカバーするのに十分ではない場合があります。

ヒント

マルチテナント アプリケーションでは、このプロセスの一環として要求の発行者とテナント 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 でネイティブ クライアントまたはデーモン アプリを登録して、ユーザーまたはそれらのために 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 によって提供されるガイダンスに従って更新する必要もあります。

次のステップ