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

  • [アーティクル]

アプリの発行元ドメインは、ユーザーに情報の送信先を知らせます。 発行元ドメインは、発行元の確認の入力または前提条件としても機能します。 アプリが登録された時期や、発行元の確認の状態によっては、これがアプリケーションの同意プロンプトでユーザーに直接表示されます。 アプリケーションの発行元ドメインは、ユーザーに各自の情報が信頼性のためにどこに送信されているかを知らせるために、同意 UX で (発行元の確認の状態に応じて) ユーザーに表示されます。

アプリの同意プロンプトに、発行元ドメインまたは発行元の確認の状態が表示されます。 表示される情報は、アプリがマルチテナント アプリかどうか、アプリが登録された時期、アプリの発行元の確認の状態によって異なります。

マルチテナント アプリについて

"マルチテナント アプリ" は、単一の組織ディレクトリの外部にあるユーザー アカウントをサポートするアプリです。 たとえば、マルチテナント アプリは、すべての Azure Active Directory (Azure AD) の職場または学校アカウントをサポートしている場合や、Azure AD の職場または学校アカウントと個人用 Microsoft アカウントの両方をサポートしている場合があります。

既定の発行元ドメインの値を理解する

いくつかの要因によって、アプリの発行元ドメインに設定される既定値が決まります。

  • アプリがテナントに登録されているかどうか。
  • テナントにテナント検証済みドメインがあるかどうか。
  • アプリの登録日。

テナント登録とテナント検証済みドメイン

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

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

次の表では、シナリオの例を使用して、発行元ドメインの既定値について説明します。

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

アプリの登録日

アプリの登録日によって、アプリの既定の発行元ドメイン値も決定されます。

マルチテナント アプリが "2019 年 5 月 21 日から 2020 年 11 月 30 日の間" に登録された場合:

  • アプリの発行元ドメインが設定されていないか、または .onmicrosoft.com で終わるドメインに設定されている場合、アプリの同意プロンプトには発行元ドメインの値に "未確認" が表示されます。
  • アプリに検証済みのアプリ ドメインがある場合は、同意プロンプトに検証済みドメインが表示されます。
  • アプリが発行元確認済みである場合、発行元ドメインには状態を示す青い "確認済み" バッジが表示されます。

マルチテナントが "2020 年 11 月 30 日以降" に登録された場合:

  • アプリの発行元が確認されていない場合は、アプリの同意プロンプトに "未確認" が表示されます。 発行元ドメインに関連する情報は表示されません。
  • アプリが発行元確認済みである場合、アプリの同意プロンプトに青い "確認済み" バッジが表示されます。

2019 年 5 月 21 日の前に作成されたアプリ

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

Azure portal で発行元ドメインを設定する

Azure portal を使用してアプリの発行元ドメインを設定するには、次の手順を実行します。

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

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

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

  4. [概要] の [管理] のリソース メニューで、[ブランド化] を選択します。

  5. [発行元ドメイン] で、次のいずれかのオプションを選択します。

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

  6. アプリがテナントで登録されている場合は、次の 2 つのオプションから選択します。

    • 確認済みドメインの選択
    • 新しいドメインの確認

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

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

アプリの新しい発行元ドメインを検証するには、次の手順を実行します。

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

    {
   "associatedApplications": [
      {
         "applicationId": "<your-app-id>"
      },
      {
         "applicationId": "<another-app-id>"
      }
   ]
 }

  2. <your-app-id> をアプリのアプリケーション (クライアント) ID に置き換えます。 複数のアプリの新しいドメインを確認する場合は、関連するすべてのアプリ ID を使用します。

  3. このファイルを https://<your-domain>.com/.well-known/microsoft-identity-association.json でホストします。 <your-domain> を確認済みドメインの名前に置き換えます。

  4. [ドメインを検証して保存] を選択します。

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

確認済みドメインの選択

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

注意

コンテンツは逆シリアル化のために UTF-8 JSON として解釈されます。 返す必要があるサポートされている 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 日より前に作成されたアプリのアプリ同意プロンプトに発行元ドメインがどのように表示されるかを示しています。

2019 年 5 月 21 日より前に作成されたアプリの同意プロンプトの動作を示す図。

2019 年 5 月 21 日から 2020 年 11 月 30 日までの間に作成されたアプリの場合、アプリの同意プロンプトに発行元ドメインがどのように表示されるかは、発行元ドメインとアプリの種類によって異なります。 次の図では、さまざまな構成の組み合わせで同意プロンプトに表示される内容について説明します。

2019 年 5 月 21 日から 2020 年 11 月 30 日の間に作成されたアプリの同意プロンプトの動作を示す図。

2020 年 11 月 30 日以降に作成されたマルチテナント アプリの場合、アプリの同意プロンプトには発行元の確認状態のみが表示されます。 次の表では、アプリが検証されているかどうかに応じて同意プロンプトに表示される内容について説明します。 シングルテナント アプリの同意プロンプトは変わりません。

2020 年 11 月 30 日より後に作成されたアプリの同意プロンプトの結果を示す図。

発行元ドメインとリダイレクト 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 を使用してプログラムで発行元ドメインを設定することはできません。

次のステップ