この記事では、ご使用の Microsoft Entra テナントのユーザーのみ、任意の Microsoft Entra テナントのユーザー、個人の Microsoft アカウントを持つユーザーのいずれをアプリが許可するかを開発者が選択する方法について説明します。 Microsoft Entra でのアプリの登録時に、アプリをシングル テナントまたはマルチテナントに構成できます。 アプリが必要なアクセス許可のみを要求するように、最小限の特権アクセスの ゼロ トラスト 原則を確認します。
Microsoft ID プラットフォームでは、特定の ID の種類がサポートされます。
- エンティティに Microsoft Entra ID のアカウントがある場合の職場または学校アカウント。
- Outlook.com、Hotmail、Live、Skype、Xbox などにアカウントを持つすべてのユーザーの Microsoft 個人用アカウント (MSA)。
- パートナー (組織外のユーザー) の Microsoft Entra ID の外部 ID。
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 プラットフォームにはエンタープライズ アプリという 2 つ目のオブジェクトがあります。 エンタープライズ アプリは、 サービス プリンシパルとも呼ばれます。
他のテナントのユーザーや他のコンシューマー アカウントを持つアプリ
サポートされているアカウントの種類には、マルチテナント アプリケーション の任意の組織ディレクトリ オプションのアカウント が含まれているため、組織のディレクトリ ユーザーを許可できます。 つまり、ユーザーが任意の 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 ID にアプリを追加する方法と理由は 、アプリケーション オブジェクトが Microsoft Entra ID に対してアプリケーションを記述する方法を説明します。
- Microsoft Entra ID のアプリケーション プロパティのセキュリティのベスト プラクティス では、リダイレクト URI、アクセス トークン、証明書とシークレット、アプリケーション ID URI、アプリケーションの所有権などのプロパティについて説明します。
- ID に対するゼロ トラスト アプローチを使用してアプリを構築すると 、アクセス許可とアクセスのベスト プラクティスの概要が提供されます。
- リソースにアクセスするための承認を取得 すると、アプリケーションのリソース アクセス許可を取得するときにゼロ トラストを最も確実にする方法を理解するのに役立ちます。
- 委任されたアクセス許可戦略を開発 すると、アプリケーションでアクセス許可を管理するための最適なアプローチを実装し、ゼロ トラスト原則を使用して開発することができます。
- アプリケーションのアクセス許可戦略を開発 すると、資格情報管理に対するアプリケーションのアクセス許可アプローチを決定するのに役立ちます。