Microsoft Entra ID での認証と認可
Microsoft Entra IDでは、OAuth 2.0 や OpenID Connect などの最新の ID プロトコルがサポートされています。 MSAL4J などのライブラリは、すべてのプロトコル操作を実装することなく、アプリケーションでこれらのプロトコルを使用するのに役立ちます。
ポータル サイトのシナリオでは、Microsoft Entra IDは ID プロバイダーです。 ポータルは、アカウントの認証とトークンの発行に依存していますが、ポータルには独自のセッションと承認の決定に対する責任があります。
認証
認証 は、ID を確立して検証します。 ユーザー向けアプリケーションの場合、"このユーザーは誰ですか?" という質問に答えます。
OpenID Connect は、OAuth 2.0 に ID レイヤーを追加します。 アプリケーションは、認証されたユーザーと認証イベントに関する要求を含む ID トークン を受け取ることができます。 ID トークンは、クライアント アプリケーションを対象としています。アプリケーションがMicrosoft Graphに送信するトークンではありません。
認可
承認 によって、操作を実行する権限またはデータにアクセスするためのアクセス許可が ID に付与されているかどうかが決まります。 "このユーザーまたはアプリケーションは何を実行できるか" という質問に答えます。
OAuth 2.0 には、保護された API の アクセス トークンを 取得するためのフローが用意されています。 ポータル のシナリオでは、Microsoft Graph アクセス トークンを使用すると、ポータルは、付与されたアクセス許可に従って、サインインしているユーザーに代わって特定のデータを要求できます。
次の表は、ポータルの認証と承認の役割を示しています。
| 懸念 | ポータルの例 |
|---|---|
| 認証 | Microsoft Entra IDはアカウントを認証し、ポータルはサインイン フローを通じて ID トークンを受け取ります。 |
| API 認可 | Microsoft Graph アクセス トークンは、サインインしているユーザーのプロファイルを読み取る委任されたアクセス許可を持ちます。 |
| アプリケーション認証 | ポータルは、独自のページまたはビジネス操作へのアクセスを制御する追加のルールを適用します。 |
認証が成功しても、すべてのページまたは API へのアクセス権が自動的に付与されるわけではありません。 たとえば、テナント メンバーシップだけでは、個人が従業員であることが確立されません。
アプリケーション登録
アプリケーション登録は、Microsoft Entra ID 内のアプリケーションを定義します。 アプリケーションの ID を確立し、サインイン対象ユーザーやリダイレクト URI などの設定を記録します。 登録は、Azure ポータル、Azure CLI、またはMicrosoft Graph API を使用して管理できます。このモジュールでは登録は作成されません。
サポートされているアカウントの種類によって、サインイン対象ユーザーが定義されます。
- この組織のディレクトリ内のアカウント は、選択したテナントのユーザー アカウントとゲスト アカウントを含む、シングルテナントの対象ユーザーのみを識別します。
- 任意の組織ディレクトリのアカウントでは、マルチテナント設計のMicrosoft Entraテナントのアカウントを使用できます。
- 組織のディレクトリ内のアカウントと個人用Microsoft アカウントでは、個人のMicrosoft アカウントも許可されます。
- 個人用Microsoft アカウントでは、対象ユーザーを個人のMicrosoft アカウント (Outlook.com アカウントなど) に制限します。
登録には、プロトコル要求でアプリケーションを識別するアプリケーション (クライアント) ID があります。 機密性の高い Web アプリケーションでは、トークンの取得中にアプリケーション資格情報を使用して自身を認証します。 クライアント ID と資格情報の目的は異なります。識別子はシークレットではありません。
次のユニットでは、登録例を解釈し、その設定をコード サンプルに接続します。