トークンのカスタマイズ

  • [アーティクル]

開発者が Microsoft Entra ID と行う主なやりとりは、ユーザーを識別するためのトークンの要求です。 また、Web API を呼び出す承認を取得するためのトークンの要求も行います。 Web API トークンは、API が特定の要求に応える際に何をすることができるかを決定します。 この記事では、トークンで受け取ることができる情報と、トークンをカスタマイズする方法について説明します。 ここで紹介するゼロ トラスト開発者のベスト プラクティスは、最小特権の原則に基づいてアプリケーションのセキュリティを強化しながら、柔軟性とコントロールを向上させるのに役立つでしょう。

アプリケーション トークンをカスタマイズする目的は、アプリケーションと API でより詳細な承認を行うためにどんなプロセスを使用するかにより異なります。 たとえば、アプリケーション内には、トークンからの情報に依存するさまざまなユーザー ロール、アクセス レベル、および機能が存在します。

Microsoft Graph API は、Microsoft 365 全体にわたるロバストなディレクトリ情報とデータのセットを提供します。 Microsoft Graph のデータを基に構築することで、きめ細かで充実した承認システムを開発できます。 たとえば、ユーザーのグループ メンバーシップ、詳細なプロファイル データ、SharePoint、Outlook の情報にアクセスして、承認の決定に利用することができます。 Microsoft Entra ID からのトークンに承認データを含めることもできます。

アプリケーション レベルの承認

IT エキスパートは、トークンをカスタマイズしたり、開発者にコードを追加してもらう必要なしに、アプリケーション レベルの承認を追加することができます。

IT エキスパートは、ユーザー割り当てが必要のフラグを使用して特定のユーザーのみがアプリケーションにサインインできるようにすることで、テナント内の任意のアプリケーションにトークンが発行されるのを防ぐことができます。 このフラグがないと、テナント内のすべてのユーザーがアプリケーションにアクセスできることになります。 このフラグを設けると、割り当てられたユーザーとグループのみがアプリケーションにアクセスできます。 割り当てられたユーザーがアプリケーションにアクセスすると、アプリケーションはトークンを受け取ります。 ユーザーが割り当てを持っていない場合、アプリはトークンを受け取れません。 トークンを受け取ることのできないトークン要求もスムーズに処理できる体制を整えておくこと。

トークンのカスタマイズ メソッド

トークンをカスタマイズするには、省略可能なクレームとクレームマッピングの 2 つの方法があります。

省略可能なクレーム

省略可能なクレームは、Microsoft Entra ID からアプリケーションに送信されるトークンにどんなクレームを含めさせるかを指定します。 次のような目的に省略可能なクレームを使用できます。

  • アプリケーショントークンに含めるクレームのタイプを増やす。
  • Microsoft ID プラットフォームからトークンで返されるクレームの動作を変更する。
  • アプリケーションにカスタムのクレームを追加してアクセスする。

省略可能なクレームは、定義されたスキーマを使用してアプリケーション登録オブジェクトにぶら下がっています。 省略可能なクレームは、実行されている場所に関係なくそのアプリケーションに適用されます。 特にマルチテナント アプリケーションを作成する場合、省略可能なクレームは Microsoft Entra ID 内のすべてのテナントに対して一貫性があるため適切に機能します。 たとえば、IP アドレスはテナント固有ではありませんが、アプリケーションには IP アドレスがあります。

既定では、テナント内のゲスト ユーザーもアプリケーションにサインインできます。 ゲスト ユーザーをブロックしたい場合は、 省略可能なクレームにオプトイン (acct) します。 値が 1 の場合、ユーザーにはゲスト分類があります。 ゲストをブロックしたい場合は、acct==1 でトークンをブロックします。

クレーム マッピング

Microsoft Entra ID では、ポリシー オブジェクトは、組織内の個々のアプリケーションまたはすべてのアプリケーションに適用される規則のセットを表します。 クレーム マッピング ポリシーは、Microsoft Entra ID が特定のアプリケーション向けにトークン内で発行するクレームを修正します。

スキーマがないテナント固有の情報 (従業員 ID、部門名など) にはクレームマッピングを使用してください。 クレーム マッピングは、テナント管理者が制御するサービス プリンシパル レベルで適用されます。 クレーム マッピングは、エンタープライズ アプリケーションまたはそのアプリケーションのサービス プリンシパルに対応します。 各テナントは、それぞれ独自のクレーム マッピングを持つことができます。

基幹業務アプリケーションを開発する場合は、そのテナントに何が出来るか (そのテナントに対してどんなクレームをトークン内で使用できるか) を具体的に確認することができます。 たとえば、組織がオンプレミスの Active Directory にユーザーの部門名プロパティ (Microsoft Entra ID の標準フィールドではない) を持っている場合は、Microsoft Entra Connect を使用してこれを Microsoft Entra ID に同期することができます。

標準の拡張属性のいずれかを使用して、その情報を含めることができます。 (すべてのテナントに適用されない場合でも) 対応する拡張機能から作成できる、部門名クレームを使用してトークンを定義できます。 たとえば、ある組織が部門名を拡張属性 13 に設定するとします。

クレーム マッピングにより、属性 7 に部門名を入れる別のテナントに対してもこれを機能させることができます。

トークンのカスタマイズの計画

どのタイプのトークンをカスタマイズするかは、アプリケーションの種類 (クライアント アプリケーションまたは API) によって異なります。 トークンをカスタマイズするためにできる操作には違いはありません。 トークンに格納できる内容は、どのトークンでも同じです。 どのタイプのトークンを選んでカスタマイズするかは、アプリケーションがどのタイプのトークンを消費するかに応じて決定してください。

ID トークンのカスタマイズ

クライアント アプリケーションを開発している場合は、ユーザーを 識別するために要求するトークンであるため、ID トークンをカスタマイズします。 トークン内のオーディエンスクレーム (aud) がアプリケーションのクライアント ID と一致する場合、そのトークンはアプリケーションに属します。 API を実装していないクライアント アプリケーションが API を呼び出す場合には、アプリケーションの ID トークンのみをカスタマイズしてください。

Azure ポータルと Microsoft Graph API を使用すれば、アクセス トークンもアプリケーション向けにカスタマイズすることができますが、そのようなカスタマイズには意味がありません。 自分が所有していない API のアクセス トークンをカスタマイズすることはできません。 あなたが開発するアプリケーションは、API を呼び出す承認の根拠としてクライアント アプリケーションが受け取るアクセス トークンをデコードしたり検査してはなりません。

アクセス トークンのカスタマイズ

API を開発している場合は、クライアントの API 呼び出しの一部としてAPI がアクセス トークンを受け取るため、アクセス トークンをカスタマイズしてください。

クライアント アプリケーションは、ユーザーを識別するために受け取る ID トークンを常にカスタマイズします。 API は、API の呼び出しの一部として API が受け取るアクセス トークンをカスタマイズします。

グループとアプリ ロール

最も一般的な承認手法の 1 つは、ユーザーのグループ メンバーシップまたは割り当てられたロールに基づいたアクセスを執行することです。 グループ クレームとアプリケーション ロールをトークンに設定するでは、アプリケーション ロール定義を使用してアプリケーションを構成し、セキュリティ グループをアプリケーション ロールに割り当てて柔軟性とコントロールを向上させ、最小特権の原則でアプリケーションのゼロ トラスト セキュリティを強化する方法を説明します。

次のステップ