次の方法で共有

トークンのカスタマイズ

  • [アーティクル]

開発者が 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 が特定のアプリケーション向けにトークン内で発行するクレームを修正します。

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

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

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

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

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

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

ID トークンをカスタマイズする

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

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

アクセス トークンをカスタマイズする

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

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

グループとアプリ ロール

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

次のステップ