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