次の方法で共有

トークンのカスタマイズ

開発者として、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 portal と Microsoft Graph API を使用すると、アプリのアクセス トークンもカスタマイズできますが、それらのカスタマイズは効果がありません。 所有していない API のアクセス トークンをカスタマイズすることはできません。 アプリは、API を呼び出す承認としてクライアント アプリが受け取るアクセス トークンのデコードや検査を試みてはならないことに注意してください。

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

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

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

グループとアプリロール

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

次のステップ

  • Last updated on