シングルテナント アプリとマルチテナント アプリの ID およびアカウントのタイプ

  • [アーティクル]

この記事では、開発者として、Microsoft Entra テナントのユーザー、Microsoft Entra テナント、または個人用 Microsoft アカウントを持つユーザーのみをアプリで許可するかどうかを選択する方法について説明します。 Azure でのアプリの登録時に、シングルテナントかマルチテナントのいずれかとなるようにアプリを構成できます。 必要なアクセス許可のみをアプリが要求するように、最低特権アクセスのゼロ トラスト原則を適用してください。

Microsoft ID プラットフォームでは、特定の ID タイプがサポートされています。

  • エンティティに Microsoft Entra ID のアカウントがある場合の職場または学校アカウント
  • Outlook.com、Hotmail、Live、Skype、Xbox などにアカウントを持つすべてのユーザーの Microsoft 個人用アカウント (MSA)。
  • パートナー (組織外のユーザー) に対する Microsoft Entra ID での External Identities
  • 顧客が他の ID プロバイダーを取り込めるソリューションを作成できるMicrosoft Entra Business to Customer (B2C)。 Azure AD B2C を使用するアプリケーション、または Azure Active Directory B2C で Microsoft Dynamics 365 Fraud Protection にサブスクライブしているアプリケーションは、新しいアカウントの作成や、クライアントのエコシステムへのサインインを試みた後に、不正行為の可能性を評価できます。

Microsoft Entra ID でのアプリケーション登録に必要なものは、サポートされているアカウント タイプの選択です。 管理者の役割である IT 担当者はテナント内のアプリに対して同意できるユーザーを決定しますが、開発者はアカウント タイプに基づいてアプリを使用できるユーザーを指定します。 テナントで Microsoft Entra ID にアプリケーションを登録できない場合、管理者は別のメカニズムを介してそれらの詳細をユーザーに伝える方法を提供します。

アプリケーションの登録時には、サポートされている次のアカウント タイプから選択します。

  • Accounts in this organizational directory only (O365 only - Single tenant)
  • Accounts in any organizational directory (Any Azure AD directory - Multitenant)
  • Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
  • Personal Microsoft accounts only

この組織ディレクトリのみにあるアカウント - シングル テナント

この組織ディレクトリのみ (O365 のみ - シングル テナント) にあるアカウントを選択すると、開発者がアプリを登録したテナントのユーザーとゲストのみが許可されます。 このオプションは基幹業務 (LOB) アプリケーションで最も一般的です。

任意の組織ディレクトリのみにあるアカウント (マルチテナント)

任意の組織ディレクトリ (任意の Microsoft Entra ディレクトリ - マルチテナント) にあるアカウントを選択すると、任意の Microsoft Entra ディレクトリのすべてのユーザーがマルチテナント アプリケーションにサインインできるようになります。 特定のテナントからのユーザーのみを許可する場合は、id_tokenの tid 要求が許可されたテナントの一覧にあることを確認して、コード内のこれらのユーザーをフィルタリングします。 アプリケーションでは、組織のエンドポイントまたは共通エンドポイントを使用して、ユーザーのホーム テナント内のユーザーをサインインさせることができます。 マルチテナント アプリへのゲスト ユーザーのサインインをサポートするには、ユーザーがゲストであるテナントの特定のテナント エンドポイントを使用してユーザーをサインインさせます。

任意の組織アカウントおよび個人用 Microsoft アカウントのアカウント

任意の組織アカウントおよび個人用 Microsoft アカウントのアカウント (任意の Microsoft Entra ディレクトリ - マルチテナント) と個人用 Microsoft アカウント (Skype、Xbox など) を選択すると、ユーザーは Microsoft Entra テナントまたはコンシューマー アカウントのネイティブ ID を使用してアプリケーションにサインインできます。 テナントのフィルタリングとエンドポイントの使用は、前述のようにマルチテナント アプリと同じようにこれらのアプリに適用されます。

個人用 Microsoft アカウントのみ

個人用 Microsoft アカウントのみを選択すると、コンシューマー アカウントを持つユーザーのみがアプリを使用できるようになります。

顧客に相対するアプリケーション

Microsoft ID プラットフォームで顧客にリーチするソリューションを構築する場合、通常は企業ディレクトリを使用しません。 代わりに、会社の企業リソースにアクセスできないように、顧客を別のディレクトリに配置します。 このニーズを満たすために、マイクロソフトでは Microsoft Entra Business to Customer (B2C) を提供しています。

Azure AD B2C では、サービスとしての企業-消費者間 (B2C) ID が提供されます。 ユーザーがアプリ専用のユーザー名とパスワードを持てるようにすることができます。 B2C は、パスワードを減らすためにソーシャル ID を持つ顧客をサポートしています。 Azure AD B2C ディレクトリを顧客の Microsoft Entra ID (または SAML をサポートする任意の ID プロバイダー) を OpenID Connect にフェデレーションすることで、企業顧客をサポートできます。 マルチテナント アプリとは異なり、アプリでは、企業アセットを保護している顧客の企業ディレクトリは使用されません。 顧客は、アプリに企業リソースへのアクセスを許可することなく、サービスまたは機能にアクセスできます。

開発者だけが行えるものではない

アプリにサインインできるユーザーをアプリケーションの登録で定義している間、最終決定は個々のユーザーまたはユーザーのホーム テナントの管理者から行われます。 テナント管理者は、多くの場合、サインインできるユーザーだけでなく、アプリもより詳細に制御したいと考えます。 たとえば、アプリに条件付きアクセス ポリシーを適用したり、アプリケーションの使用を許可するグループを制御したりできます。 テナント管理者がこの制御をできるようにするために、Microsoft ID プラットフォームにはエンタープライズ アプリという 2 つ目のオブジェクトがあります。 エンタープライズ アプリは、サービス プリンシパルともいいます。

他のテナントまたは他のコンシューマー アカウントのユーザーがいるアプリの場合

2 つのテナント (架空の組織 Adatum と Contoso) の例を使用した次の図に示すように、サポートされているアカウント タイプには、組織のディレクトリ ユーザーを許可できるように、マルチテナント アプリケーションに対する任意の組織ディレクトリにあるアカウントのオプションがあります。 つまり、ユーザーが Microsoft Entra ID のネイティブ ID を使用してアプリケーションにサインインすることを許可することになります。 テナントの最初のユーザーがアプリに対して認証を行うと、サービス プリンシパルがテナントに自動的に作成されます。

図は、マルチテナント アプリケーションで組織のディレクトリ ユーザーを許可する方法を示しています。

アプリケーションの登録またはアプリケーション オブジェクトは 1 つだけです。 ただし、すべてのテナントでエンタープライズ アプリまたはサービス プリンシパル (SP) を使用すると、ユーザーはアプリにサインインできます。 テナント管理者は、テナントでのアプリの動作を制御できます。

マルチテナント アプリに関する考慮事項

マルチテナント アプリは、アプリが共通または組織のエンドポイントを使用する場合に、ユーザーのホーム テナントからユーザーをサインインさせます。 次の図に示すように、アプリには 1 つのアプリ登録があります。 この例では、アプリケーションが Adatum テナントに登録されています。 Adatum のユーザー A と Contoso のユーザー B の両方が、Adatum のユーザー A が Adatum データにアクセスし、Contoso のユーザー B が Contoso データにアクセスする想定で、アプリにサインインできます。

図は、アプリが共通エンドポイントまたは組織のエンドポイントを使用する場合に、マルチテナント アプリがユーザーのホーム テナントからユーザーにサインインする方法を示しています。

テナント情報を個別に保持するのは開発者の責任です。 たとえば、Contoso データが Microsoft Graph からである場合、Contoso のユーザー B には Contoso の Microsoft Graph データのみが表示されます。 Microsoft 365 には真のデータ分離があるため、Contoso のユーザー B が Adatum テナントの Microsoft Graph データにアクセスする可能性はありません。

上の図では、Contoso のユーザー B がアプリケーションにサインインでき、アプリケーション内の Contoso データにアクセスできます。 アプリケーションは共通の (または組織の) エンドポイントを使用できるため、ユーザーはテナントにネイティブにサインインし、招待プロセスは必要ありません。 ユーザーはアプリケーションの実行およびサインインができ、ユーザーまたはテナント管理者が同意した後で機能します。

外部ユーザーとの共同作業

企業のメンバーではないユーザーが企業のデータにアクセスできるようにする場合は、Microsoft Entra Business to Business (B2B) 機能を使用します。 次の図に示すように、企業はユーザーをテナントのゲスト ユーザーになるように招待できます。 ユーザーが招待を受け入ると、招待元テナントが保護したデータにアクセスできます。 ユーザーはテナントでの個別の認証情報を作成しません。

図は、企業がテナントにゲスト ユーザーを招待する方法を示しています。

ゲスト ユーザーは、ホーム テナント、個人用 Microsoft アカウント、またはその他の IDP アカウントにサインインして認証します。 ゲストは、任意の電子メールを使用してワンタイム パスコードで認証することもできます。 ゲストが認証されると、招待元テナントの Microsoft Entra ID によって、招待元テナントのデータにアクセスするためのトークンが提供されます。

開発者は、アプリケーションがゲスト ユーザーをサポートする場合は、次の考慮事項に留意してください。

  • ゲスト ユーザーをサインインさせる場合は、テナント固有のエンドポイントを使用する必要があります。 共通エンドポイント、組織エンドポイント、またはコンシューマー エンドポイントは使用できません。
  • ゲスト ユーザー ID は、ホーム テナントまたは他の IDP でのユーザーの ID とは異なります。 ゲスト ユーザーのトークン内の oid 要求は、ホーム テナント内の同じ個人の oid とは異なります。

次のステップ