アプリケーションの発行元ドメインを構成する

アプリケーションの発行元ドメインは、ユーザーに情報の送信先を知らせるためにアプリケーションの同意プロンプトでユーザーに表示されます。 2019 年 5 月 21 日の後に登録されたマルチテナント アプリケーションのうち、発行元ドメインのないアプリケーションは未検証として表示されます。 マルチテナント アプリケーションは、1 つの組織ディレクトリの外部にあるアカウントをサポートするアプリケーションです。たとえば、すべての Azure AD アカウントをサポートするか、またはすべての Azure AD アカウントと個人の Microsoft アカウントをサポートします。

新しいアプリケーション

新しいアプリを登録すると、そのアプリの発行元ドメインは既定値に設定される可能性があります。 この値は、アプリが登録された場所、特にアプリがテナントで登録されたかどうか、およびそのテナントにテナントで検証済みのドメインが存在するかどうかによって異なります。

テナントで検証済みのドメインが存在する場合、アプリの発行元ドメインは、既定でそのテナントの検証済みプライマリ ドメインになります。 テナントで検証済みのドメインが存在しない場合 (そのテナントでアプリケーションが登録されていない場合)、アプリの発行元ドメインは null に設定されます。

次の表は、発行元ドメイン値の既定の動作をまとめたものです。

テナントで検証済みのドメイン 発行元ドメインの既定値
null null
*.onmicrosoft.com *.onmicrosoft.com
- *.onmicrosoft.com
- domain1.com
- domain2.com (プライマリ)
domain2.com

マルチテナント アプリケーションの発行元ドメインが設定されていないか、または .onmicrosoft.com で終わるドメインに設定されている場合、アプリの同意プロンプトには発行元ドメインの代わりに未検証が表示されます。

条件が適用されないアプリケーション

アプリが 2019 年 5 月 21 日の前に登録された場合は、発行元ドメインを設定していなくても、アプリケーションの同意プロンプトに未検証は表示されません。 ユーザーがアプリの同意プロンプトでこの情報を確認できるように、発行元ドメイン値を設定することをお勧めします。

Azure Portal を使用して発行元ドメインを構成する

アプリの発行元ドメインを設定するには、次の手順に従います。

  1. Azure portal にサインインします。

  2. 複数のテナントにアクセスできる場合は、上部のメニューの [ディレクトリとサブスクリプション] フィルター を使用して、アプリが登録されているテナントを選択します。

  3. [Azure Active Directory] > [アプリの登録] に移動し、構成するアプリを見つけて選択します。

    アプリを選択すると、アプリの [概要] ページが表示されます。

  4. [管理] 下にある [ブランド] を選択します。

  5. [発行元ドメイン] フィールドを見つけ、次のいずれかのオプションを選択します。

    • ドメインがまだ構成されていない場合は、 [ドメインの構成] を選択します。
    • ドメインが既に構成されている場合は、 [ドメインを更新] を選択します。

アプリがテナントで登録されている場合は、選択するタブとして [確認済みドメインの選択][新しいドメインの確認] の 2 つが表示されます。

ドメインがテナントで登録されていない場合は、アプリケーションの新しいドメインを検証するためのオプションのみが表示されます。

アプリの新しいドメインを検証するには

  1. microsoft-identity-association.json という名前のファイルを作成し、次の JSON コード スニペットを貼り付けます。

    {
       "associatedApplications": [
          {
             "applicationId": "{YOUR-APP-ID-HERE}"
          },
          {
             "applicationId": "{YOUR-OTHER-APP-ID-HERE}"
          }
       ]
     }
    
  2. プレースホルダー {YOUR-APP-ID-HERE} をアプリに対応するアプリケーション (クライアント) ID に置き換えます。

  3. このファイルを https://{YOUR-DOMAIN-HERE}.com/.well-known/microsoft-identity-association.json でホストします。 プレースホルダー {YOUR-DOMAIN-HERE} を検証済みのドメインに一致するように置き換えます。

  4. [ドメインを検証して保存] ボタンをクリックします。

ドメインの検証後、検証に使用されるリソースを保持する必要はありません。 検証が完了したら、ホストされているファイルは削除できます。

検証済みのドメインを選択するには

テナントに検証済みのドメインが存在する場合は、 [確認済みドメインの選択] ドロップダウンからいずれかのドメインを選択します。

注意

返される必要がある Content-Type ヘッダーは application/json です。 application/json; charset=utf-8 のようにそれ以外のものを使用するとエラーが発生する場合があります。

Verification of publisher domain failed. Error getting JSON file from https:///.well-known/microsoft-identity-association. The server returned an unexpected content type header value.

発行元ドメインを構成すると、アプリの同意プロンプトでユーザーに表示される内容に影響を与えます。 同意プロンプトのコンポーネントを完全に理解するには、アプリケーションの同意エクスペリエンスの理解に関するページを参照してください。

次の表では、2019 年 5 月 21 日の前に作成されたアプリケーションの動作について説明します。

Consent prompt for apps created before May 21, 2019

2019 年 5 月 21 日の後に作成された新しいアプリケーションの動作は、発行元ドメインとアプリケーションの種類によって異なります。 次の表では、さまざまな構成の組み合わせで表示されることが予測される内容の変化について説明します。

Consent prompt for apps created after May 21, 2019

リダイレクト URI への影響

ユーザーが職場または学校アカウントあるいは個人の Microsoft アカウント (マルチテナント) でサインインするアプリケーションは、リダイレクト URI を指定するときにいくつかの制限に従います。

単一のルート ドメインの制限

マルチテナント アプリの発行元ドメイン値が null に設定されている場合、アプリは、リダイレクト URI に関して単一のルート ドメインを共有するように制限されます。 たとえば、ルート ドメイン contoso.com は fabrikam.com に一致しないため、次の値の組み合わせは許可されません。

"https://contoso.com",
"https://fabrikam.com",

サブドメインの制限

サブドメインは許可されますが、ルート ドメインを明示的に登録する必要があります。 たとえば、次の URI は単一のルート ドメインを共有していますが、この組み合わせは許可されません。

"https://app1.contoso.com",
"https://app2.contoso.com",

ただし、開発者がルート ドメインを明示的に追加した場合、この組み合わせは許可されます。

"https://contoso.com",
"https://app1.contoso.com",
"https://app2.contoso.com",

例外

次のケースは、単一のルート ドメインの制限に従いません。

  • シングル テナント アプリ、または 1 つのディレクトリ内のアカウントを対象にするアプリ
  • リダイレクト URI としての localhost の使用
  • カスタム スキームを含むリダイレクト URI (HTTP 以外または HTTPS)

プログラムで発行元ドメインを構成する

現在、プログラムで発行元ドメインを構成するための REST API または PowerShell のサポートはありません。