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

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

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

  • エンティティが Azure Active Directory (AD) にアカウントを持っている場合の職場または学校アカウント

  • outlook.com、Hotmail、Live、Skype、Xbox などのアカウントを持つすべてのユーザー向けの Microsoft 個人アカウント (MSA)。

  • パートナー (組織外のユーザー) の Azure AD の外部 ID

  • Azure AD Business to Customer (B2C) を使用すると、顧客が他の ID プロバイダーを持ち込むソリューションを作成できます。

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

アプリケーションを登録するときに、次のサポートされているアカウントの種類のオプションから選択します。

  • この組織ディレクトリ内のアカウントのみ (O365 のみ - シングル テナント)

  • 任意の組織のディレクトリ内のアカウント (任意の Azure AD ディレクトリ - マルチテナント)

  • 任意の組織ディレクトリ内のアカウント (任意の Azure AD ディレクトリ - マルチテナント) と個人の Microsoft アカウント (Skype、Xbox など)

  • 個人用 Microsoft アカウントのみ

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

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

任意の組織のディレクトリ内のアカウントのみ - マルチテナント

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

任意の組織アカウントと個人用 Microsoft アカウントのアカウント

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

個人用 Microsoft アカウントのみ

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

顧客向けアプリケーション

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

Azure Active Directory B2C は、サービスとしての企業-消費者間 (B2C) ID が提供されます。 B2C では、アプリユーザーがアプリ専用のユーザー名とパスワードを持つことができるようにするだけでなく、ユーザーが持ち込めるソーシャル ID を持つ顧客をサポートできるため、より多くのパスワードを覚える必要がなくなります。 たとえば、ユーザーに Facebook または Twitter ID の使用を許可できます。 また、Azure AD B2C ディレクトリを顧客の Azure AD (または SAML をサポートする任意の ID プロバイダー (IDP)) と OpenID Connect をフェデレーションすることで、エンタープライズ顧客をサポートすることもできます。 マルチテナント アプリとは異なり、アプリでは、顧客が企業資産を保護している会社のディレクトリは使用されません。 B2C を使用すると、顧客は、アプリに企業リソースへのアクセスを許可することなく、サービスまたは機能にアクセスできます。

開発者だけが行うものではありません。

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

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

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

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

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

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

マルチテナント アプリは、アプリが共通または組織のエンドポイントを使用するときに、ユーザーのホーム テナントからユーザーをサインインさせます。 次の図に示すように、アプリには 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 データにアクセスできます。 アプリケーションでは共通のエンドポイント (組織) を使用できるため、ユーザーはテナントの場所を問わずテナントにネイティブにサインインし、招待プロセスは必要ありません。 ユーザーはアプリケーションを実行してサインインするだけで、ユーザーまたはテナント管理者が同意した後に機能します。

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

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

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

ゲスト ユーザーが認証する必要がある場合は、ホーム テナント、個人用 Microsoft アカウント、別の IDP のアカウント、または任意の電子メール アカウントを使用してワンタイム パスコードを使用してサインインします。 IDP で認証された後、招待元テナントの Azure AD は、テナント内のゲスト ユーザーとして識別するトークンをアプリケーションに提供します。 このゲスト ユーザーは、招待するテナント内のデータにアクセスできます。

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

  • ゲスト ユーザーにサインインするときは、テナント固有のエンドポイントを使用する必要があります。 共通エンドポイント、組織エンドポイント、またはコンシューマー エンドポイントは使用できません。

  • ゲスト ユーザー ID は、ホーム テナントまたはその他の IDP 内のユーザーの ID とは異なります。 つまり、ゲスト ユーザーのトークン内の oid 要求は、ホーム テナント内の同じ個人の oid とは異なります。

次のステップ