アプリケーションは、ユーザー自身をサインインさせたり、サインインを ID プロバイダーに委任したりできます。 この記事では、アプリケーションを Microsoft ID プラットフォームに登録するために必要な手順について説明します。
アプリケーションを登録する
ユーザーが特定のアプリにアクセスできるかどうかを ID プロバイダーが認識するには、ユーザーとアプリケーションの両方を ID プロバイダーに登録する必要があります。 アプリケーションを Microsoft Entra ID に登録すると、アプリケーションの ID 構成が提供されます。これにより、アプリケーションは Microsoft ID プラットフォームと統合できます。 アプリを登録すると、次のことができます。
- サインイン ダイアログ ボックスでアプリケーションのブランドをカスタマイズします。 サインインは、ユーザーがアプリで最初に使用するエクスペリエンスであるため、このブランド化は重要です。
- ユーザーが組織に属している場合にのみサインインを許可するかどうかを決定します。 このアーキテクチャは、シングルテナント アプリケーションと呼ばれます。 または、マルチテナント アプリケーションと呼ばれる任意の職場または学校アカウントを使用して、ユーザーにサインインを許可することもできます。 LinkedIn や Google などの個人用 Microsoft アカウントやソーシャル アカウントを許可することもできます。
- スコープのアクセス許可を要求します。 たとえば、サインインしているユーザーのプロファイルを読み取るためのアクセス許可を付与する "user.read" スコープを要求できます。
- Web API へのアクセスを定義するスコープを定義します。 通常、アプリが API にアクセスする場合は、定義したスコープへのアクセス許可を要求する必要があります。
- アプリの ID を証明する Microsoft ID プラットフォームとシークレットを共有します。 シークレットの使用は、アプリが機密クライアント アプリケーションである場合に関連します。 機密 クライアント アプリケーション は、 Web クライアントのように資格情報を安全に保持できるアプリケーションです。 資格情報を格納するには、信頼できるバックエンド サーバーが必要です。
アプリが登録されると、トークンを要求するときに Microsoft ID プラットフォームと共有する一意の識別子が付与されます。 アプリが機密クライアント アプリケーションの場合、証明書またはシークレットが使用されたかどうかに応じて、シークレットまたは公開キーも共有されます。
Microsoft ID プラットフォームは、次の 2 つの主要な機能を満たすモデルを使用してアプリケーションを表します。
- サポートされている認証プロトコルによってアプリを識別します。
- 認証に必要なすべての識別子、URL、シークレット、関連情報を指定します。
Microsoft ID プラットフォーム:
- 実行時に認証をサポートするために必要なすべてのデータを保持します。
- アプリがアクセスする必要があるリソースと、特定の要求を満たす必要がある状況を決定するためのすべてのデータを保持します。
- アプリ開発者のテナント内および他の Microsoft Entra テナントにアプリ プロビジョニングを実装するためのインフラストラクチャを提供します。
- トークン要求時にユーザーの同意を処理し、テナント間でのアプリの動的プロビジョニングを容易にします。
同意 とは、リソース所有者に代わって、特定のアクセス許可の下で、保護されたリソースにアクセスするための承認をクライアント アプリケーションに付与するリソース所有者のプロセスです。 Microsoft ID プラットフォームでは、次のことが可能になります。
- ユーザーと管理者は、アプリが自分の代わりにリソースにアクセスするための同意を動的に許可または拒否します。
- 管理者は最終的に、実行できるアプリと、特定のアプリを使用できるユーザー、およびディレクトリ リソースへのアクセス方法を決定します。
マルチテナント アプリ
重要
マルチテナント アプリケーション (MTA) は、各クラウド内でサービス プリンシパル機関が分離されているため、クラウド境界を越えて機能しません。 たとえば、アプリケーション オブジェクトが商用クラウドでホストされている場合、関連付けられているサービス プリンシパルは、顧客のオンボード中にローカルに作成されます。 このプロセスは、機関 URL が異なるため (たとえば、 .com と .us)、非互換性が発生するため、クラウド境界を越えると失敗します。
Microsoft ID プラットフォームでは、 アプリケーション オブジェクト によってアプリケーションが記述されます。 デプロイ時に、Microsoft ID プラットフォームは、アプリケーション オブジェクトをブループリントとして使用して サービス プリンシパルを作成します。これは、ディレクトリまたはテナント内のアプリケーションの具体的なインスタンスを表します。 サービス プリンシパルは、アプリが特定のターゲット ディレクトリで実際に実行できる内容、使用できるユーザー、アクセスできるリソースなどを定義します。 Microsoft ID プラットフォームは、同意を通じてアプリケーション オブジェクトからサービス プリンシパルを作成します。
次の図は、同意によって駆動される簡略化された Microsoft ID プラットフォームのプロビジョニング フローを示しています。 A と B の 2 つのテナントが表示されます。
- テナント A はアプリケーションを所有します。
- テナント B は、サービス プリンシパルを使用してアプリケーションをインスタンス化しています。
このプロビジョニング フローでは、次の操作を行います。
- テナント B のユーザーがアプリでサインインを試みます。 承認エンドポイントは、アプリケーションのトークンを要求します。
- ユーザー資格情報が取得され、認証用に検証されます。
- ユーザーは、アプリがテナント B にアクセスするための同意を求められます。
- Microsoft ID プラットフォームは、テナント A のアプリケーション オブジェクトを、テナント B にサービス プリンシパルを作成するためのブループリントとして使用します。
- ユーザーは要求されたトークンを受け取ります。
このプロセスは、より多くのテナントに対して繰り返すことができます。 テナント A は、アプリ (アプリケーション オブジェクト) のブループリントを保持します。 アプリに同意が与えられている他のすべてのテナントのユーザーと管理者は、各テナントの対応するサービス プリンシパル オブジェクトを介してアプリケーションが実行できる操作を制御します。 詳細については、「 Microsoft ID プラットフォームのアプリケーション オブジェクトとサービス プリンシパル オブジェクト」を参照してください。
次のステップ
Microsoft ID プラットフォームでの認証と承認の詳細については、次の記事を参照してください。
- 認証と承認の基本的な概念については、「認証と承認」を参照してください。
- アクセス トークン、更新トークン、および ID トークンを認証と承認で使用する方法については、「 セキュリティ トークン」を参照してください。
- Web、デスクトップ、モバイル アプリのサインイン フローについては、「 アプリのサインイン フロー」を参照してください。
- トークン クレームを使用した適切な認可については、「クレームを検証してアプリケーションと API をセキュリティで保護する」を参照してください
アプリケーション モデルの詳細については、次の記事を参照してください。
- Microsoft ID プラットフォームのアプリケーション オブジェクトとサービス プリンシパルの詳細については、「アプリケーションが Microsoft Entra ID に追加される方法と理由」を参照してください。
- シングルテナント アプリとマルチテナント アプリの詳細については、「 Microsoft Entra ID のテナント」を参照してください。
- Microsoft Entra ID が Azure Active Directory B2C を提供して、組織がユーザー (通常は顧客) を Google アカウントなどのソーシャル ID を使用してサインインできるようにする方法の詳細については、 Azure Active Directory B2C のドキュメントを参照してください。