Microsoft ID プラットフォームでのアクセス許可と同意の概要

Microsoft ID プラットフォームでは、保護されたリソースへのアクセスを必要とするセキュリティで保護されたアプリケーションを開発するために、アクセス許可と同意を理解することが重要です。 この記事では、アクセス許可と同意に関連する基本的な概念とシナリオの概要について説明し、アプリケーション開発者がユーザーと管理者に必要な承認を要求するのに役立ちます。 これらの概念を理解することで、アプリケーションが必要とするアクセスのみを要求し、信頼とセキュリティを確保できます。

電子メールや予定表データなどの保護されたリソースにアクセスするには、アプリケーションでリソース所有者の承認が必要です。 リソース所有者は、アプリの要求に同意または拒否できます。 これらの基本的な概念を理解すると、ユーザーと管理者から必要なアクセスのみを要求する、より安全で信頼できるアプリケーションを構築するのに役立ちます。

アクセスのシナリオ

アプリケーション開発者は、アプリケーションがデータにアクセスする方法を特定する必要があります。 アプリケーションでは、サインイン ユーザーの代わりに動作する委任アクセス、またはアプリケーションの専用 ID としてのみ動作するアプリ専用のアクセスを使用できます。

委任アクセス (ユーザーの代わりにアクセス)

このアクセス シナリオでは、ユーザーはクライアント アプリケーションにサインインしています。 クライアント アプリケーションは、ユーザーの代わりにリソースにアクセスします。 委任アクセスでは、委任されたアクセス許可が必要です。 クライアントとユーザーの両方に、要求を行うための許可を個別に付与する必要があります。 委任アクセスのシナリオの詳細については、委任アクセスのシナリオに関する記事を参照してください。

クライアント アプリの場合、適切な委任されたアクセス許可を付与する必要があります。 委任されたアクセス許可は、スコープとも呼ばれます。 スコープは、クライアント アプリケーションでユーザーの代わりにアクセスできる対象を表す、特定のリソースのアクセス許可です。 スコープについて詳しくは、「スコープとアクセス許可」を参照してください。

ユーザーの場合、承認は、ユーザーがリソースにアクセスするために付与される特権に依存します。 たとえば、Microsoft Entra のロールベースのアクセス制御 (RBAC) によって、ディレクトリ リソースにアクセスするための許可をユーザーに付与でき、また Exchange Online の RBAC によって、メールと予定表のリソースにアクセスするための許可をユーザーに付与できます。 アプリケーションの RBAC の詳細については、「アプリケーションの RBAC」を参照してください。

アプリ専用のアクセス (ユーザーが関与しないアクセス)

このアクセス シナリオでは、ユーザーがサインインしていない状態でアプリケーションが単独で動作します。 アプリケーション アクセスは、自動化やバックアップなどのシナリオで使用されます。 このシナリオには、バックグラウンド サービスやデーモンとして実行されるアプリが含まれます。 特定のユーザーをサインインさせたくない場合や、複数のユーザーに対してデータが必要になる場合に適しています。 アプリ専用アクセス シナリオの詳細については、「 アプリ専用アクセス」を参照してください。

アプリ専用のアクセスでは、委任されたスコープではなくアプリ ロールが使用されます。 同意によって付与されたアプリ ロールは、アプリケーションのアクセス許可とも呼ばれます。 クライアント アプリには、呼び出し先となるリソース アプリの適切なアプリケーション アクセス許可を付与する必要があります。 付与後、クライアント アプリでは、要求されたデータにアクセスできます。 クライアント アプリケーションへのアプリ ロールの割り当てについて詳しくは、「アプリケーションへのアプリ ロールの割り当て」を参照してください。

アクセス許可の種類

委任されたアクセス許可は、委任アクセス シナリオで使用されます。 これらは、ユーザーの代わりにアプリケーションが動作できるようにするアクセス許可です。 アプリケーションは、サインインしているユーザーがアクセスできなかったものにアクセスできません。

たとえば、ユーザーに代わって委任されたアクセス許可 Files.Read.All 付与されたアプリケーションを取得します。 アプリケーションは、ユーザーが個人的にアクセスできるファイルのみを読み取ることができます。

アプリケーションのアクセス許可 (アプリ ロールとも呼ばれる) は、サインイン ユーザーが関与しないアプリ専用のアクセスのシナリオで使用されます。 アプリケーションは、アクセス許可が関連付けられているすべてのデータにアクセスできます。

たとえば、Microsoft Graph API のアプリケーションアクセス許可 Files.Read.All 付与されたアプリケーションは、Microsoft Graph を使用してテナント内の任意のファイルを読み取ることができるとします。 一般的に、ある API のサービス プリンシパルの管理者または所有者のみが、その API によって公開されるアプリケーションのアクセス許可に同意できます。

委任されたアクセス許可とアプリケーションのアクセス許可の比較

同意

アプリケーションにアクセス許可を付与する方法の 1 つは、同意による方法です。 同意とは、アプリケーションが保護されたリソースにアクセスすることを、ユーザーまたは管理者が承認するプロセスです。 たとえば、ユーザーが初めてアプリケーションにサインインしようとしたとき、そのアプリケーションで、ユーザーのプロファイルを表示し、ユーザーのメールボックスの内容を読み取るためのアクセス許可を要求できます。 ユーザーには、同意プロンプトを通じて、アプリが要求しているアクセス許可の一覧が表示されます。 同意プロンプトがユーザーに表示されるその他のシナリオは次のとおりです。

• 以前に許可された同意が取り消されたとき。
• サインイン中に特に同意を求めるようにアプリケーションがコーディングされているとき。
• アプリケーションが動的な同意を使って、実行時に必要に応じて新しいアクセス許可を要求する場合。

同意プロンプトの主要な詳細情報は、アプリケーションが必要とするアクセス許可の一覧とパブリッシャー情報です。 管理者とエンド ユーザーの両方の同意プロンプトと同意エクスペリエンスの詳細については、 アプリケーションの同意エクスペリエンスに関するページを参照してください。

ユーザーの同意

ユーザーの同意は、ユーザーがアプリケーションにサインインしようとしたときに行われます。 ユーザーはサインイン資格情報を提供します。この資格情報は、同意が既に付与されているかどうかを判断するためにチェックされます。 必要なアクセス許可へのユーザーまたは管理者の同意を示すレコードがない場合、ユーザーには同意プロンプトが表示され、要求されたアクセス許可をアプリケーションに付与するように求められます。 管理者は、ユーザーに代わって同意を付与する必要がある場合があります。

管理者の同意

必要なアクセス許可によっては、一部のアプリケーションでは、管理者が同意を付与することが必要になる場合があります。 たとえば、アプリケーションのアクセス許可と多くの強い権限の委任されたアクセス許可には、管理者のみが同意できます。

管理者は、自分自身または組織全体のために同意を行うことができます。 ユーザーと管理者の同意について詳しくは、ユーザーと管理者の同意の概要に関するページを参照してください。

認証要求では、同意が付与されていない場合、およびこれらの高い権限のアクセス許可のいずれかが要求された場合、管理者の同意を求められます。

カスタム アプリケーション スコープを含むアクセス許可要求は高い特権とは見なされないため、管理者の同意は必要ありません。

事前承認

事前認証を使用すると、リソース アプリケーションの所有者は、事前認証されたのと同じアクセス許可セットに対する同意プロンプトをユーザーに表示することなく、アクセス許可を付与できます。 このように、事前認証されたアプリケーションでは、アクセス許可に同意するようにユーザーに求められません。 リソース所有者は、Azure portal で、または PowerShell や Microsoft Graph などの API を使用して、クライアント アプリを事前認証できます。

ほとんどの場合、Microsoft Entra External ID の顧客向けアプリケーションはすべて事前認証を必要とします。これは、組織に所属せず、アプリケーションによって要求されたアクセス許可に同意できないユーザーを対象としているためです。 事前認証により、これらのユーザーは同意を求められることなく、アプリケーションにアクセスできるようになります。

その他の認可システム

同意フレームワークは、アプリケーションまたはユーザーが保護されたリソースにアクセスすることを認可する方法の 1 つにすぎません。 管理者は、機密情報へのアクセスを許可している他の認可システムを把握しておく必要があります。 Microsoft のさまざまな承認システムの例としては、 Microsoft Entra 組み込みロール、 Azure RBAC、 Exchange RBAC、 Teams リソース固有の同意などがあります。

関連項目

• Microsoft ID プラットフォームでの委任されたアクセスのシナリオ
• Microsoft Entra ID におけるユーザーと管理者の同意
• Microsoft ID プラットフォームでのスコープとアクセス許可
• Microsoft Entra ID でシングルテナント アプリをマルチテナントに変換する
• Microsoft Entra Microsoft Q&A