Azure Active Directory v1.0 エンドポイントでのアクセス許可と同意
警告
このコンテンツは、以前の Azure AD v1.0 エンドポイント用です。 新しいプロジェクトには Microsoft ID プラットフォームを使用します。
Azure Active Directory (Azure AD) では、OAuth フローと OpenID Connect (OIDC) フローの両方でアクセス許可を広く利用します。 アプリが Azure AD から受け取るアクセス トークンには、特定のリソースに関してアプリに付与されたアクセス許可を示す要求が含まれています。
"スコープ" とも呼ばれる "アクセス許可" を使用すると、リソースに対する承認が容易になります。リソースはアプリが呼び出すどの API に対しても適切なアクセス許可がトークンに含まれていることを確認するだけで済むためです。
アクセス許可の種類
Azure AD では、次の 2 種類のアクセス許可が定義されています。
- 委任されたアクセス許可 - サインインしているユーザーが存在するアプリで使用されます。 これらのアプリでは、ユーザーまたは管理者がアプリから要求されたアクセス許可に同意すると、API の呼び出し時にサインイン ユーザーとして動作するためのアクセス許可がアプリに委任されます。 API によっては、ユーザーが API に直接同意することができない場合があり、代わりに "管理者の同意" が必要になります。
- アプリケーションのアクセス許可 - サインインしているユーザーが存在しない状態で実行されるアプリ (バックグラウンド サービスまたはデーモンとして実行されるアプリなど) で使用されます。 通常、アプリケーションのアクセス許可は非常に強力であり、ユーザー境界を越えるデータや管理者に限定されたデータへのアクセスを許可するため、これらのアクセス許可には管理者だけが同意できます。 リソース アプリケーション (つまり、アクセス許可を発行する API) の所有者として定義されているユーザーも、自分が所有している API に対するアプリケーション アクセス許可を付与することができます。
有効なアクセス許可は、アプリが API に要求を行うときに付与されるアクセス許可です。
- 委任されたアクセス許可の場合、アプリの有効なアクセス許可は、(同意によって) アプリに付与されている委任されたアクセス許可と現在サインインしているユーザーの特権の共通部分の最小特権になります。 サインインしているユーザーよりも多くの特権をアプリに付与することはできません。 組織内では、サインインしているユーザーの特権は、ポリシーによって決定することも、1 つ以上の管理者ロールのメンバーシップによって決定することもできます。 委任されたアクセス許可に同意できる管理者ロールについては、「Azure AD での管理者ロールのアクセス許可」を参照してください。
たとえば、Microsoft Graph で委任されたアクセス許可として
User.ReadWrite.Allがアプリに付与されているとします。 通常、このアクセス許可は、組織内のすべてのユーザーのプロファイルを読み取り、更新する権限をアプリに付与します。 サインインしているユーザーが全体管理者の場合、アプリは組織内のすべてのユーザーのプロファイルを更新できます。 ただし、サインインしているユーザーが管理者ロールに属していない場合、アプリが更新できるのは、サインインしているユーザーのプロファイルだけになります。 アプリにはユーザーの代理で動作するためのアクセス許可が付与されていますが、そのユーザーに組織内の他のユーザーのプロファイルを更新する権限がないため、アプリがこれを実行することはできません。 - アプリケーションのアクセス許可の場合、アプリの有効なアクセス許可は、そのアクセス許可が暗示する完全なレベルの権限になります。 たとえば、アプリケーションのアクセス許可として
User.ReadWrite.Allが付与されているアプリは、組織内のすべてのユーザーのプロファイルを更新できます。
アクセス許可の属性
Azure AD のアクセス許可には、ユーザー、管理者、またはアプリ開発者が、そのアクセス許可によって付与されるアクセスの対象について、情報に基づいて判断するのに役立つ多数のプロパティがあります。
Note
Azure AD アプリケーションまたはサービス プリンシパルが公開するアクセス許可は、Azure portal または PowerShell を使用して表示できます。 次のスクリプトを実行して、Microsoft Graph で公開されているアクセス許可を表示してみてください。
Connect-AzureAD
# Get OAuth2 Permissions/delegated permissions
(Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'").OAuth2Permissions
# Get App roles/application permissions
(Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'").AppRoles
| プロパティ名 | 説明 | 例 |
|---|---|---|
ID |
このアクセス許可を一意に識別する GUID 値です。 | 570282fd-fa5c-430d-a7fd-fc8dc98a9dca |
IsEnabled |
このアクセス許可が使用可能かどうかを示します。 | true |
Type |
このアクセス許可にユーザーの同意と管理者の同意のどちらが必要かを示します。 | User |
AdminConsentDescription |
管理者の同意エクスペリエンスで管理者に表示される説明です。 | ユーザーのメールボックスのメールを読み取ることをアプリに許可します。 |
AdminConsentDisplayName |
管理者の同意エクスペリエンスで管理者に表示されるフレンドリ名です。 | ユーザーのメールの読み取り |
UserConsentDescription |
ユーザーの同意エクスペリエンスでユーザーに表示される説明です。 | ユーザーが自分のメールボックスのメールを読み取ることをアプリに許可します。 |
UserConsentDisplayName |
ユーザーの同意エクスペリエンスでユーザーに表示されるフレンドリ名です。 | メールの読み取り |
Value |
OAuth 2.0 認可フローにおいて、アクセス許可の識別に使用される文字列です。
Value は、完全修飾アクセス許可名を形成するために、アプリ ID URI 文字列と組み合わせることもできます。 |
Mail.Read |
同意の種類
Azure AD のアプリケーションでは、必要なリソースや API へのアクセス権を取得するために同意を利用します。 成功を収めるために、アプリが認識しておく必要があると考えられる多くの種類の同意があります。 アクセス許可を定義する場合は、ユーザーがアプリや API へのアクセス権を取得する方法も理解しておく必要があります。
静的なユーザーの同意 - アプリが対話する必要があるリソースを指定すると、OAuth 2.0 認可フローで自動的に発生します。 静的なユーザーの同意シナリオでは、Azure portal のアプリの構成で、アプリに必要なすべてのアクセス許可が既に指定されている必要があります。 ユーザー (または、必要に応じて管理者) がこのアプリに同意していなかった場合、Azure AD によって、現時点でユーザーに同意を求めるメッセージが表示されます。
API の静的セットへのアクセスを要求する Azure AD アプリの登録の詳細をご覧ください。
動的なユーザーの同意 - v2 Azure AD アプリ モデルの機能です。 このシナリオでは、アプリは、v2 アプリの OAuth 2.0 認可フローで必要な一連のアクセス許可を要求します。 ユーザーがまだ同意していなかった場合、現時点で同意を求められます。 動的な同意の詳細については、こちらをご覧ください。
重要
動的な同意は便利な場合もありますが、大きな問題もあります。 管理者の同意を必要とするアクセス許可の場合、同意する時点では、管理者の同意エクスペリエンスがこれらのアクセス許可を把握していないことです。 管理者特権のアクセス許可が必要な場合、またはアプリが動的な同意を使用する場合は、Azure portal で (管理者の同意が必要なアクセス許可のサブセットだけでなく) すべてのアクセス許可を登録する必要があります。 これにより、テナント管理者が、すべてのユーザーを代表して同意できます。
管理者の同意 - 特定の高い権限のアクセス許可がアプリに必要な場合に必要となります。 管理者の同意により、管理者は、組織の高い権限が必要なデータにアプリやユーザーがアクセスすることを承認する前に制御を強化できます。 管理者の同意を付与する方法の詳細については、こちらをご覧ください。
ベスト プラクティス
クライアントのベスト プラクティス
- アプリに必要なアクセス許可だけを要求します。 アプリに付与されているアクセス許可が多すぎると、アプリが侵害された場合に、ユーザー データが公開される危険性があります。
- アプリがサポートするシナリオに基づいて、委任されたアクセス許可とアプリケーション アクセス許可のいずれかを選択します。
- 呼び出しがユーザーに代わって行われる場合は、常に委任されたアクセス許可を使用します。
- アプリが非対話型で、特定のユーザーに代わって呼び出しを行わない場合にのみ、アプリケーション アクセス許可を使用します。 アプリケーション アクセス許可は高度な特権を持つため、絶対に必要な場合にのみ使用します。
- v2.0 エンドポイントに基づくアプリを使用する場合は、常に静的アクセス許可 (アプリケーション登録で指定されるもの) が実行時に要求する動的アクセス許可 (コードで指定され、承認要求のクエリ パラメーターとして送信されるもの) のスーパーセットになるように設定して、管理者の同意などのシナリオが正しく機能するようにします。
リソース/API のベスト プラクティス
- API を公開するリソースでは、保護するデータまたはアクションに固有のアクセス許可を定義します。 このベスト プラクティスに従うと、クライアントには不要なデータへのアクセス許可が付与されなくなり、ユーザーには同意対象のデータに関する十分な情報が提供されるようになります。
- リソースでは、
Readアクセス許可とReadWriteアクセス許可をそれぞれ明示的に定義します。 - リソースでは、ユーザー境界を越えるデータへのアクセスを許可するすべてのアクセス許可を
Adminアクセス許可としてマークします。 - リソースは
Subject.Permission[.Modifier]という名前付けパターンに従う必要があります。このパターンで、Subjectは、利用可能なデータの種類に対応しますPermissionは、ユーザーがそのデータに対して行うアクションに対応しますModifierは、別のアクセス許可の特殊化を記述するためにオプションで使用されます次に例を示します。
Mail.Read - ユーザーにメールの読み取りを許可します。
Mail.ReadWrite - ユーザーにメールの読み取りまたは書き込みを許可します。
Mail.ReadWrite.All - 管理者またはユーザーに、組織内のすべてのメールへのアクセスを許可します。