アプリケーション専用アクセスについて
アプリケーションが Microsoft Graph などのリソースに直接アクセスする場合、そのアクセスは、1 人のユーザーが使用できるファイルや操作に限定されません。 アプリは独自の ID を使用して API を直接呼び出し、管理者権限を持つユーザーまたはアプリがリソースへのアクセスを承認する必要があります。 このシナリオは、アプリケーション専用アクセスです。
アプリケーション専用アクセスを使用する必要があるのはどのような場合ですか?
ほとんどの場合、アプリケーション専用アクセスは委任されたアクセスよりも広範かつ強力であるため、必要な場合にのみアプリ専用アクセスを使用する必要があります。 通常は、次の場合に適しています。
- ユーザーによる入力なしで、自動化された方法でアプリケーションを実行する必要がある。 たとえば、特定の連絡先からのメールをチェックして自動応答を送信する日次のスクリプトなどです。
- アプリケーションで、複数の異なるユーザーのリソースにアクセスする必要がある。 たとえば、バックアップ アプリやデータ損失防止アプリでは、それぞれ異なる参加者がいるさまざまなチャット チャンネルからメッセージを取得する必要がある場合があります。
- 資格情報をローカルに保存し、アプリでユーザーまたは管理者 "として" サインインできるようにする必要がある。
これに対し、ユーザーが通常サインインして独自のリソースを管理する場合は、アプリケーション専用アクセスを使用しないでください。 このようなシナリオでは、最小限の特権となるように委任されたアクセスを使用する必要があります。
アプリケーション専用の呼び出しをアプリに許可する
アプリ専用の呼び出しを行うには、クライアント アプリに適切なアプリ ロールを割り当てる必要があります。 アプリ ロールは、アプリケーション専用のアクセス許可とも呼ばれます。 これらは、ロールを定義するリソース アプリのコンテキストでのみアクセス権を付与するため、"アプリ" ロールです。
たとえば、組織内で作成されたすべてのチームの一覧を読み取るために、アプリケーションに Microsoft Graph Team.ReadBasic.All アプリ ロールを割り当てる必要があります。 このアプリ ロールでは、Microsoft Graph がリソース アプリである場合に、このデータを読み取る権限が付与されます。 これを割り当てても、クライアント アプリケーションに、他のサービスを介してこのデータを表示できる可能性のある Teams ロールは割り当てられません。
開発者は、アプリケーションの登録時に、必要なすべてのアプリ専用アクセス許可 (アプリ ロールとも呼ばれます) を構成する必要があります。 アプリの要求されたアプリ専用アクセス許可は、Azure portal または Microsoft Graph を使用して構成できます。 アプリ専用アクセスでは動的な同意がサポートされていないため、実行時に個々のアクセス許可やアクセス許可のセットを要求することはできません。
アプリに必要なすべてのアクセス許可を構成したら、リソースにアクセスするために管理者の同意を得る必要があります。 たとえば、グローバル管理者ロールを持つユーザーのみが、Microsoft Graph API のアプリ専用アクセス許可 (アプリ ロール) を付与できます。 アプリケーション管理者やクラウド アプリ管理者などの他の管理者ロールを持つユーザーは、他のリソースに対するアプリ専用アクセス許可を付与できます。
管理者ユーザーは、Azure portal を使用するか、Microsoft Graph API を使用してプログラムで許可を作成することにより、アプリ専用アクセス許可を付与できます。 アプリ内から対話型の同意を求めることもできますが、アプリ専用アクセスではユーザーを必要としないため、このオプションは推奨されません。
Outlook.com や Xbox Live アカウントなどの Microsoft アカウントを持つコンシューマー ユーザーは、アプリケーション専用アクセスを承認することはできません。
常に最小限の特権の原則に従ってください。アプリで必要でないアプリ ロールは要求しないでください。 この原則に従えば、アプリが侵害された場合のセキュリティ リスクを限定するのに役立ち、管理者がアプリにアクセスを付与しやすくなります。 たとえば、アプリ専用で詳細なプロファイル情報を読み取らずにユーザーを識別する必要がある場合は、User.Read.All ではなく、より制限された Microsoft Graph User.ReadBasic.All アプリ ロールを要求する必要があります。
リソース サービス用のアプリ ロールの設計と発行
Microsoft Entra ID 上でサービスを構築し、他のクライアントが呼び出す API を公開している場合、アプリ ロール (アプリ専用アクセス許可) による自動アクセスをサポートすることもできます。 アプリケーションのアプリ ロールは、Microsoft Entra 管理センター のアプリ登録の [アプリ ロール] セクションで定義できます。 アプリ ロールを作成する方法の詳細については、「アプリケーションのロールを宣言する」を参照してください。
他のユーザーが使用するアプリ ロールを公開する場合は、そのロールを割り当てる管理者にシナリオの明確な説明を提供します。 アプリ専用アクセスはユーザー権限の制約を受けないため、通常アプリ ロールはできるだけ狭くし、特定の機能シナリオをサポートするようにする必要があります。 サービスに含まれるすべての API とリソースへのフル read アクセスまたはフル read/write アクセスを許可する単一のロールを公開することは避けてください。
注意
アプリ ロール (アプリ専用アクセス許可) は、ユーザーやグループへの割り当てをサポートするように構成することもできます。 目的のアクセス シナリオに合わせてアプリ ロールを正しく構成してください。 API のアプリ ロールをアプリ専用アクセスに使用する場合は、アプリ ロールの作成時に、許可される唯一のメンバーの種類としてアプリケーションを選択します。
アプリケーション専用アクセスが機能する仕組み
アプリ専用アクセスについて覚えておくべき最も重要なことは、呼び出し元のアプリ自体が代理として、また独自の ID として機能することです。 ユーザーによる操作はありません。 アプリがリソースの特定のアプリ ロールに割り当てられている場合、そのアプリには、そのアプリ ロールによって管理されるすべてのリソースと操作に対して完全に制約のないアクセス権が付与されています。
アプリが 1 つ以上のアプリ ロール (アプリ専用アクセス許可) に割り当てられると、クライアント資格情報フローまたはその他のサポートされる認証フローを使用して、アプリから Microsoft Entra ID にアプリ専用トークンを要求できます。 割り当てられたロールは、アプリのアクセス トークンの roles 要求に追加されます。
シナリオによっては、委任された呼び出しのユーザー権限と同様に、アプリケーション ID によってアクセスが許可されるかどうかが決定される場合があります。 たとえば、Application.ReadWrite.OwnedBy アプリ ロールでは、アプリ自体が所有するサービス プリンシパルを管理する権限がアプリに付与されます。
アプリケーション専用アクセスの例 - Microsoft Graph を使用した自動電子メール通知
次の例は、現実的な自動化シナリオを示しています。
Alice は、Windows ファイル共有に存在する部門レポート フォルダーで新しいドキュメントが登録されるたびに、電子メールでチームに通知したいと考えています。 Alice は、フォルダーを調べて新しいファイルを検索する PowerShell スクリプトを実行するスケジュールされたタスクを作成します。 このスクリプトでは、リソース API である Microsoft Graph によって保護されたメールボックスを使用して電子メールを送信します。
スクリプトはユーザーの操作なしで実行されるため、認可システムではアプリケーションの認可のみがチェックされます。 Exchange Online で、呼び出しを行うクライアントに、アプリケーションのアクセス許可 (アプリ ロール) Mail.Send が管理者によって付与されているかどうかがチェックされます。 Mail.Send がアプリに付与されていない場合、Exchange Online は要求に失敗します。
| POST /users/{id}/{userPrincipalName}/sendMail | クライアント アプリに Mail.Send が付与されている場合 | クライアント アプリに Mail.Send が付与されていない場合 |
|---|---|---|
| このスクリプトでは、Alice のメールボックスを使用して電子メールを送信します。 | 200 - アクセスが付与されます。 管理者が、任意のユーザーとしてメールを送信することをアプリに許可しました。 | 403 - 承認されません。 管理者が、電子メールの送信をこのクライアントに許可していません。 |
| このスクリプトでは、電子メールを送信するための専用メールボックスを作成します。 | 200 - アクセスが付与されます。 管理者が、任意のユーザーとしてメールを送信することをアプリに許可しました。 | 403 - 承認されません。 管理者が、電子メールの送信をこのクライアントに許可していません。 |
上記の例は、アプリケーションの認可を簡単に示したものです。 運用環境の Exchange Online サービスでは、アプリケーションのアクセス許可を特定の Exchange Online メールボックスに制限するなど、他にもさまざまなアクセス シナリオがサポートされています。