アクセス許可と同意の概要

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

アクセスのシナリオ

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

アクセス シナリオの図を示す画像。

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

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

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

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

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

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

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

アクセス許可の種類

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

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

アプリケーションのアクセス許可 (アプリ ロールと呼ばれることもあります) は、サインイン ユーザーが関与しないアプリ専用のアクセスのシナリオで使用されます。 アプリケーションは、アクセス許可が関連付けられているすべてのデータにアクセスできます。 たとえば、Files.Read.All というアプリケーションのアクセス許可が付与されたアプリケーションは、テナント内のすべてのファイルを読み取ることができます。 管理者またはサービス プリンシパルの所有者のみ、アプリケーションのアクセス許可に同意できます。

他の方法でも、アプリ専用のアクセスの認可をアプリケーションに付与できます。 たとえば、アプリケーションに Azure AD の RBAC ロールを割り当てることができます。

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

デリゲートされたアクセス許可 アプリケーションのアクセス許可
アプリの種類 Web/モバイル/シングルページ アプリ (SPA) Web/デーモン
アクセスのコンテキスト ユーザーの代理でアクセスを取得する ユーザーなしでアクセスを取得する
同意できるユーザー - ユーザーは自分のデータに同意できます
- 管理者はすべてのユーザーに同意できます
管理者のみが同意できます
同意の方法 - 静的: アプリ登録時に構成されたリスト
- 動的: ログイン時に個別のアクセス許可を要求
- 静的のみ: アプリ登録時に構成されたリスト
その他の名前 - スコープ
- OAuth2 アクセス許可のスコープ
- アプリ ロール
- アプリ専用のアクセス許可
同意の結果 (Microsoft Graph に固有) oAuth2PermissionGrant appRoleAssignment

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

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

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

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

必要なアクセス許可によっては、一部のアプリケーションでは、管理者が同意を付与することが必要になる場合があります。 たとえば、アプリケーションのアクセス許可と多くの強い権限の委任されたアクセス許可には、管理者のみが同意できます。 管理者は、自分自身または組織全体のために同意を行うことができます。 ユーザーと管理者の同意について詳しくは、ユーザーと管理者の同意の概要に関するページを参照してください。

事前承認

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

次の手順