シングルテナント アプリとマルチテナント アプリの ID とアカウントの種類

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

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、または OpenID Connect に対して Security Assertion Markup Language (SAML) をサポートする任意の ID プロバイダーとフェデレーションすることで、エンタープライズ顧客をサポートできます。 マルチテナント アプリとは異なり、アプリでは、企業アセットを保護している顧客の企業ディレクトリは使用されません。 顧客は、アプリに企業リソースへのアクセスを許可することなく、サービスまたは機能にアクセスできます。

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

アプリにサインインできるユーザーをアプリケーションの登録で定義している間、最終決定は個々のユーザーまたはユーザーのホーム テナントの管理者から行われます。 テナント管理者は、多くの場合、サインインできるユーザーだけでなく、アプリもより詳細に制御したいと考えます。 たとえば、アプリへの条件付きアクセス ポリシーの適用や、アプリケーションの使用を許可するグループの制御を求めることがあります。 テナント管理者がこの制御をできるようにするために、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 アカウント、またはその他の ID プロバイダー (IDP) アカウントにサインインして認証します。 ゲストは、任意の電子メールを使用してワンタイム パスコードで認証することもできます。 ゲストが認証されると、招待元テナントの Microsoft Entra ID によって、招待元テナントのデータにアクセスするためのトークンが提供されます。

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

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

次のステップ

• 「アプリケーションを Microsoft Entra ID に追加する方法と理由」では、アプリケーション オブジェクトが Microsoft Entra ID に対してアプリケーションを記述する方法を説明しています。
• 「Microsoft Entra ID でのアプリケーション プロパティのセキュリティに関するベスト プラクティス」では、リダイレクト URI、アクセス トークン、証明書とシークレット、アプリケーション ID URI、アプリケーションの所有権などのプロパティについて説明しています。
• 「ID に対するゼロ トラストアプローチを使用したアプリの構築」では、アクセス許可とアクセスのベスト プラクティスの概要について説明しています。
• 「リソースにアクセスするための承認の取得」は、アプリケーション用にリソースのアクセス許可を取得するときにゼロ トラストを確保する最善の方法を理解するのに役立ちます。
• 「委任されたアクセス許可戦略の策定」は、アプリケーションのアクセス許可を管理するための最適なアプローチを実装し、ゼロ トラスト原則を使用して策定するのに役立ちます。
• 「アプリケーションのアクセス許可戦略の開発」は、資格情報管理に対するアプリケーションのアクセス許可のアプローチを決定するのに役立ちます。