Microsoft Entra ID エコシステムでアプリケーションを確立する

  • [アーティクル]

Microsoft Entra ID でアプリケーションを構築するときは、最初にアプリケーションの ID を確立します。 アプリでトークンを要求するには、Microsoft Entra ID の ID が必要です。 アプリケーション プログラミング インターフェイス (API) で、アプリがリソースにアクセスするためのトークンを発行するには、Microsoft Entra ID の ID が必要です。

この記事では、Microsoft Entra 管理センターで、または Microsoft Graph API を使って、アプリを Microsoft Entra ID テナントに登録する方法を説明します。 これは、独立系ソフトウェア開発者 (ISV) が Microsoft Entra ID 用にアプリケーションを構築および最適化する方法に関する一連の記事の 2 つ目です。 このシリーズでは、次のトピックについて詳しく説明します。

  • 独立系ソフトウェア開発者向けの Microsoft Entra ID に関する記事では、このクラウドベースの ID およびアクセス管理サービスを使用して、従業員がアプリケーションでリソースにアクセスできるようにする方法について説明します。
  • アプリケーションとユーザーの認証に関する記事では、アプリケーションが Microsoft Entra ID を使用してユーザーとアプリケーションを認証する方法について説明します。
  • アプリケーション、リソース、ワークロードの認可に関する記事では、個々のユーザーがアプリケーションを操作して指示する場合、API がユーザーに代わって動作する場合、アプリケーションまたはサービスが独立して動作する場合について説明します。
  • 「トークンのカスタマイズ」は、Microsoft Entra ID の ID トークンとアクセス トークンを使用してアプリケーションにセキュリティを組み込むのに役立ちます。 Microsoft Entra ID トークンで受け取ることができる情報と、それらをカスタマイズする方法について説明します。

アプリケーションの登録

開発者は、アプリケーションをマルチテナント アプリおよびシングルテナント アプリとして登録できます。 ISV には、マルチテナント アプリをお勧めします。 マルチテナント アプリには、ISV が完全に制御してテナントに登録する 1 つのアプリ登録があります。 アプリを登録するための Microsoft Entra ID テナントを作成する方法について説明します。

Microsoft Entra ID を実行している顧客にソリューションを提供し、顧客の Microsoft Entra ID テナントにオンボードするためのシームレスなエクスペリエンスを提供するには、Microsoft Entra 管理センターで [アプリの登録] の [アプリケーションの登録] に移動します。 この新しいアプリの登録で、[サポートされているアカウントの種類] の [任意の組織のディレクトリ内のアカウント (任意の Microsoft Entra ID テナント - マルチテナント)] または [任意の組織のディレクトリ (Microsoft Entra ID テナント - マルチテナント) 内のアカウントと、個人用の Microsoft アカウント (Skype、Xbox など)] を選びます。

Microsoft Entra 管理センターでのアプリケーション構成オプションのスクリーンショット。

外部テナントへのマルチテナント アプリのオンボードは、アプリを実行し、ユーザーをアプリにサインインさせるだけで、簡単に行うことができます。 テナントでユーザーの同意が許可されている場合は (管理者が事前にアプリを承認しなくても、ユーザーはアプリにサインインできます)、アプリのオンボードは、ユーザーがアプリにサインインするだけで済みます。 こちらの開発者向け ID ワークショップ (時間コード 1:05:20 から 1:08:00) では、ユーザーがアプリにサインインするときにテナントにオンボードされるアプリが示されています。

Microsoft Entra ID テナントにアプリを登録すると、アプリのクライアント ID とも呼ばれるアプリケーション ID (アプリ ID) を受け取ります。 これは、ユーザーに対する userid のようなもので、アプリを一意に識別します。 アプリ ID は、Microsoft Entra ID クラウド全体でグローバルに一意であり、不変です。 アプリと Microsoft Entra ID の間のすべてのやり取りには、アプリ ID が含まれます。

アプリ ID に加えて、アプリの登録には、アプリ開発者が知っている、または知る必要がある、アプリに関する情報が含まれます。 たとえば、アプリ開発者は、Microsoft Entra ID と対話するためにアプリ ID を知っている必要があります。 開発者は、自分が構築しているアプリケーションの種類 (Web アプリ、ネイティブ アプリ、シングル ページ アプリ、モバイル アプリ、またはデスクトップ アプリ) を知っています。 アプリケーションの種類には必須の属性があります。

たとえば、リダイレクト Uniform Resource Identifier (URI) は必須のアプリケーション属性です。 この属性は、認証または認可の後でユーザーに送信する Web アドレス (ネイティブ アプリ アドレス) を Microsoft Entra ID に指示します。 開発者は、アプリの種類とアプリの実行場所に基づいて、アプリケーションのリダイレクト URI を知ることができます。

アプリのマニフェスト (Microsoft Entra 管理センターまたは Microsoft Graph API からアクセスします) には、多くのアプリケーション属性が格納されます。 アプリの属性と許容される値については、Microsoft Entra のアプリ マニフェストの概要に関する記事をご覧ください。

開発中のアプリに推奨される設定については、Microsoft ID プラットフォームの認証と認可のコード サンプルに関する記事をご覧ください。 構築しているアプリに似たアプリケーション サンプルを見つけて、そのドキュメントを読んでください。 サンプルでは、アプリの種類別に必要なアプリ登録の設定の詳細が示されています。 たとえば、Node.jsで API を構築している場合、こちらの登録手順に導かれるサンプルを見つけることができます。

アプリの登録では、開発者が知っていることを伝えます。 ユーザーがマルチテナント アプリに対する認証を行うことができる各テナントでは、テナント管理者がテナントでのアプリケーションの実行方法を構成します。 たとえば、テナント管理者は、アプリを特定のネットワークの場所に制限する条件付きアクセス ポリシーを設定できます。 また、ユーザーがアプリにアクセスするために多要素認証 (MFA) を必要とする条件付きアクセス ポリシーや、特定のユーザーまたはグループによるアプリの使用を許可するアプリ設定を作成できます。

テナント管理者がこのような制限を有効にするには、テナント内にアプリのための制御ポイントが必要です。 Microsoft Entra ID は、ユーザーがアプリの認証を行うエンタープライズ アプリケーションをテナントごとに自動的に作成します。 Microsoft Entra 管理センターでは、それらはエンタープライズ アプリケーションと呼ばれますが、オブジェクトはサービス プリンシパルです。 詳しくは、Microsoft Entra ID でのアプリとサービス プリンシパルに関する記事をご覧ください。

ユーザーがアプリの認証を行った後、Microsoft Entra ID によって、ユーザーが認証を行ったテナントにサービス プリンシパルが作成されます。 テナント管理者は、Microsoft Graph (または、Microsoft Entra 管理センターの [エンタープライズ アプリケーション]) でサービス プリンシパル オブジェクトを使って、テナントでのアプリの動作方法を構成できます。

サービス プリンシパルは、同じ属性を多く持っていますが、アプリ登録のコピーではありません。 そうではなく、サービス プリンシパルはアプリ登録にリンクしています。 アプリ登録の更新をリンクされたエンタープライズ アプリケーションで見ることができます。 マルチテナント アプリの場合、顧客は ISV のテナントにあるアプリ登録にアクセスすることはできません。 ただし、アプリケーションは、別のテナントにある場合でも、Microsoft Graph を使ってそのサービス プリンシパルにアクセスできます。 そのため、アプリはエンタープライズ アプリケーションに関する属性にアクセスできます (たとえば、アプリへのユーザー割り当てが必要かどうか、アプリでロールに割り当てられているユーザーなど)。

ISV のアプリ登録にはマルチテナント アプリをお勧めしますが、アプリを登録するためのもう 1 つのオプションとしてシングルテナント アプリがあります。 ISV が登録を完全に制御する ISV のテナントでの単一のアプリ登録の代わりに、アプリ用のテナントにアプリを登録するよう顧客に依頼できます。 顧客は、登録を完了した後、アプリの登録の詳細を使ってアプリ インスタンスを構成します。 このシングルテナント アプリのアプローチは、主に、特定の企業向けに開発された基幹業務アプリケーションにお勧めします。

顧客にアプリケーションの登録と構成を任せるオーバーヘッドがあるため、ISV 用のシングルテナント アプリはお勧めしません。 ただし、アプリでマルチテナント アプリを使用できないシナリオがあります。

アプリで、OpenID Connect (OIDC) または OAuth 2.0 ではなく、Security Assertion Markup Language 2.0 (SAML) を使っている場合は、シングルテナント アプリ登録モデルに従います。 SAML アプリの場合、サービス プリンシパルの作成とアプリの登録の順序は、少なくともテナントに SAML アプリを追加する管理者については、OIDC または OAuth 2.0 アプリの反対です。 アプリを登録してから、Microsoft Entra ID でサービス プリンシパルを自動的に作成するのではなく、管理者は最初にエンタープライズ アプリを作成します。 Microsoft Entra ID によって、アプリの登録が自動的に作成されます。 「アプリケーションを発行する」セクションで説明されている Microsoft Entra ID アプリ ギャラリーを使うと、管理者向けの SAML アプリ作成プロセスが容易になります。

リダイレクト Uniform Resource Identifier (URI) での制限のため、ISV がマルチテナント アプリを作成できない場合があります。 ワイルドカードを使わずに、1 つのアプリで最大 256 個のリダイレクト URI を使用できます。 アプリケーションで顧客ごとに一意のリダイレクト URI が必要であり、一意のインスタンスを必要とする顧客が 256 より多い場合、マルチテナント アプリを作成できない可能性があります。 セキュリティ上の理由から、Microsoft Entra ID リダイレクト URI ではワイルドカード (*) を使用できません。 1 つのオプションは、セントラル サービスに対する 1 つのリダイレクト URI を使用することです (セントラル サービスが可能な場合)。 セントラル リダイレクト URI は、トークンを検証した後、ユーザーを顧客固有のエンドポイントにリダイレクトします。

アプリケーションを発行する

ユーザーは、最初にアプリを認証するとき、またはユーザーのリソースへのアクセスをアプリに認可するときに、アプリを信頼するかどうかを決定します。 管理者は、テナント内のすべてのユーザーについても同様の決定を行うことができます。 管理者は、ユーザーがアプリにサインインするかどうか、およびアプリが特定のリソースにアクセスするかどうかを決定できます。

次のアプリ発行方法は、ISV がユーザーと管理者の信頼を得られるものとしてアプリを提示するのに役立ちます。

  • 確認済みドメインからアプリを発行します。 発行元ドメインは、情報を受け取る場所をユーザーと管理者に通知します。 確認済みの発行元ドメインからの発行は、アプリの登録済みテナントが、アプリの発行元として一覧で示されているドメインを制御できることを示します。
  • 発行元の確認を使用してアプリを発行します。 確認済みの発行元ドメインを使うことは、発行元の確認の前提条件であり、単にアプリの発行元がドメインを制御できることを示すだけではありません。 発行元の確認は、Microsoft がドメインとテナントの背後にあるエンティティを本物として確認したことを示します。 管理者ではないユーザーは、確認されていない発行元からのマルチテナント アプリを信頼しないことがよくあります。 管理者は、確認済み発行元からではないアプリが常に管理者の同意を必要とするようにテナントを構成できます。 発行元の確認は、主に、OAuth 2.0 と OIDC でマルチテナント アプリを構築する ISV を対象としています。 確認済みの発行元は、Microsoft Cloud Partner Program のメンバーです。 発行元の確認は、SAML や基幹業務アプリの使用など、シングルテナント アプリには影響しません。
  • Microsoft Entra ID アプリ ギャラリーでアプリを公開します。 SAML 2.0 を使っているアプリおよび OAuth 2.0 と OIDC を使っているアプリの Microsoft Entra ID アプリ ギャラリーへの掲載を Microsoft に要求できます。 管理者は、Microsoft Entra 管理センター の [エンタープライズ アプリケーション] の [新しいアプリケーション] から、Microsoft Entra ID アプリ ギャラリーで事前に統合されているアプリを検索します。 Microsoft Entra ID アプリ ギャラリーでアプリを公開すると、アプリの構成が簡単で最小限になります。 Microsoft がアプリケーションをテストして、互換性の検証を提供します。これは、使用前に構成が必要な SAML 2.0 を使うアプリにとって特に重要です。 アプリのクロスドメイン ID 管理システム (SCIM) 2.0 の実装を使って、プロビジョニング用にアプリ ギャラリーのアプリを構成できます。「自動プロビジョニング」セクションをご覧ください。 始めるには、アプリケーションの公開の要求をお送りください。 アプリ ギャラリー内の 1 つのアプリケーションで SCIM を使って、シングル サインオンとユーザー プロビジョニングを実現できます。
  • Microsoft 365 アプリ コンプライアンス プログラムに参加します。 確認済みドメインを使うと、ISV はドメインを自分で制御できます。 発行元の確認は、Microsoft が ISV の組織を本物として確認したことを示します。 Microsoft Entra ID アプリ ギャラリーへのアプリの掲載は、アプリが Microsoft Entra ID で動作し、簡単にオンボードできることを示します。 Microsoft 365 コンプライアンス プログラムを使うと、パブリッシャー構成証明、Microsoft 365 認定、または Azure での アプリ コンプライアンス自動化ツール (ACAT) により、アプリのセキュリティとコンプライアンスについて顧客に通知できます。 これは、顧客がアプリにアクセスすることを認可するリソースがアプリケーションによってどのように保護されるかを示しています。

自動プロビジョニング

Microsoft Entra ID でのアプリのプロビジョニングでは、ユーザーがアクセスする必要のあるクラウド アプリケーションにユーザー ID、グループ オブジェクト、ロールを自動的にプロビジョニングできます。 ユーザーとグループのオブジェクトの作成に加えて、自動プロビジョニングには、状態またはロールが変わったときのユーザー ID のメンテナンスと削除が含まれます。 Microsoft Entra プロビジョニング サービスは、アプリケーションが提供する SCIM オブジェクト管理 API エンドポイントを呼び出すことによって、ユーザーとグループをアプリケーションに自動的にプロビジョニングします。

ISV の場合、Microsoft Entra ID でのアプリのプロビジョニングの利点は次のとおりです。

  • Microsoft Graph を使ってアプリケーションにプロビジョニングすることができ、SCIM をサポートする ID プロバイダー (IdP) でプロビジョニングが動作できる SCIM エンドポイントが構築されます。 ほとんどの IdP は SCIM プロビジョニング プロトコルをサポートしています。
  • プロビジョニングは、Microsoft Entra ID とアプリケーションの間でデータを同期する同期操作です。 Microsoft Graph ベースの同期ソリューションを実装するには、アプリがテナント内のすべてのユーザーとグループのすべての属性にアクセスする必要があります。 Microsoft Entra ID の一部のお客様は、このような広範なアクセスを許可することに消極的です。 SCIM では、管理者はアプリケーションと同期する Microsoft Entra ID の属性を選択できます。 多くの管理者は、SCIM の実装でのみ使用できる、このきめ細かい制御が行えることを好みます。
  • ISV がプロビジョニング用に独自の Microsoft Graph 同期サービスを構築するということは、自分でそのサービスを管理し、Microsoft Entra ID で変更を監視するためのプル モデルを実装する必要があることを意味します。 SCIM エンドポイントを実装すると、Microsoft Entra ID によってプロビジョニング サービス管理が行われ、変更がアプリにプッシュされます。

SCIM、Microsoft Graph、Microsoft Entra ID を使用したユーザーのプロビジョニングと、データでのアプリのエンリッチに関する記事では、SCIM を使うべきときと Microsoft Graph を使うべきときに関するガイダンスが提供されています。 Microsoft のドキュメントを使って、Microsoft Entra ID での SCIM エンドポイントの計画、構築、確認を行い、SCIM のコンプライアンスに関する既知の問題に対処してください。

Microsoft Entra ID は、アプリケーションにデータを同期するだけでなく、クラウドベースの人事 (HR) アプリケーションでのプロビジョニングも提供します。 人事主導のプロビジョニングは、人事ソリューションに基づいてデジタル ID を作成するプロセスです。 人事システムが、新しく作成されるデジタル ID の Start of Authority として、多くの場合、さまざまなプロビジョニング プロセスの開始点となります。 オンプレミスの人事ソリューションでは、Microsoft Identity Manager を使って、ユーザーをオンプレミスの Active Directory にプロビジョニングできます。 その後、Microsoft Entra Connect を使って Microsoft Entra ID と同期するか、Microsoft Entra ID に直接同期できます。

API 駆動型のインバウンド プロビジョニングを使うと、クラウドベースの HR ISV はネイティブ同期エクスペリエンスを提供して、HR システムでの変更が Microsoft Entra ID および接続されたオンプレミス Active Directoryドメインに自動的に流れるようにできます。 たとえば、人事アプリや学生情報システム アプリは、トランザクションが完了するとすぐ、または 1 日の終わりの一括更新として Microsoft Entra ID にデータを送信できます。 API 駆動型インバウンド プロビジョニングの概念の学習を始めるには、Microsoft Graph の bulkUpload 機能について調べ、API 駆動型プロビジョニングの概念、シナリオ、制限事項についての理解を深めてください。

次のステップ

  • アプリケーションが Microsoft Entra ID で動作することを確認し、アプリケーションを発行する要求を送信します。
  • 独立系ソフトウェア開発者向けの Microsoft Entra ID に関する記事では、このクラウドベースの ID およびアクセス管理サービスを使用して、従業員がアプリケーションでリソースにアクセスできるようにする方法について説明します。
  • アプリケーションとユーザーの認証に関する記事では、アプリケーションが Microsoft Entra ID を使用してユーザーとアプリケーションを認証する方法について説明します。
  • アプリケーション、リソース、ワークロードの認可に関する記事では、個々の人間がアプリケーションを操作して指示する場合、API がユーザーの代わりに動作する場合、アプリケーションまたはサービスが独立して動作する場合の承認について説明されています。
  • 「トークンのカスタマイズ」は、Microsoft Entra ID の ID トークンとアクセス トークンを使用してアプリケーションにセキュリティを組み込むのに役立ちます。 Microsoft Entra ID トークンで受け取ることができる情報と、それらをカスタマイズする方法について説明します。