次の方法で共有

クレームを検証してアプリケーションと API をセキュリティで保護する

  • [アーティクル]

トークンの操作は、ユーザーを認可するためのアプリケーション構築の中核部分です。 最小限の特権アクセスに関するゼロ トラスト原則に従って、認可の実行時にアクセス トークン内にある特定のクレームの値をアプリケーションで検証する必要があります。

クレーム ベースの認可により、アプリケーションでは、トークン内にあるテナント、サブジェクト、アクターなどの正しい値がトークンに含まれていることを確認できます。 とはいえ、クレーム ベースの認可は、利用するためのさまざまな方法と追跡するシナリオを考えると複雑に思えるかもしれません。 この記事では、アプリケーションが最も安全なプラクティスに確実に準拠しているようにするため、クレーム ベースの認可プロセスを簡略化する予定です。

認可ロジックがセキュリティで保護されていることを確認するには、クレームで次の情報を検証する必要があります。

  • トークンに適切な対象ユーザーが指定されている。
  • トークンのテナント ID が、データが保存されているテナントの ID と一致している。
  • トークンのサブジェクトが適切である。
  • アクター (クライアント アプリ) が認可されている。

Note

アクセス トークンは、クライアントによって取得された Web API でのみ検証されます。 クライアントはアクセス トークンを検証してはなりません。

この記事で説明するクレームの詳細については、「Microsoft ID プラットフォーム アクセス トークン」を参照してください。

対象ユーザーを検証する

aud クレームにより、トークンの想定されている対象ユーザーを識別します。 クレームを検証する前に、アクセス トークンに含まれる aud クレームの値がWeb API と一致することを常に確認する必要があります。 値は、クライアントがトークンを要求した方法によって異なります。 アクセス トークンの対象ユーザーは、エンドポイントによって異なります。

  • v2.0 トークンの場合、対象ユーザーは Web API のクライアント ID です。 これは GUID です。
  • v1.0 トークンの場合、対象ユーザーは、トークンを検証する Web API で宣言されている appID URI のいずれかです。 たとえば、api://{ApplicationID}、またはドメイン名で始まる一意の名前です (ドメイン名がテナントに関連付けられている場合)。

アプリケーションの appID URI の詳細については、「アプリケーション ID URI」を参照してください。

テナントを検証する

トークンの tid が、アプリケーションでデータを保存するために使用されるテナント ID と一致することを常にチェックします。 テナントのコンテキストでアプリケーションの情報が保存されている場合、同じテナントで後でもう一度アクセスする必要があります。 あるテナント内のデータへの、別のテナントからのアクセスを許可しないでください。

テナントの検証は最初の手順に過ぎません。この記事で説明するサブジェクトとアクターに関するチェックは引き続き求められます。 テナント内のすべてのユーザーを承認することを目的とする場合は、これらのユーザーを明示的にグループに追加し、グループに基づいて承認することが強く推奨されます。 たとえば、テナント ID と oid 要求のプレゼンスを確認するだけで、API はユーザーに加えて、そのテナント内のすべてのサービス プリンシパルを誤って承認する可能性があります。

サブジェクトを検証する

ユーザー (またはアプリ専用トークン場合はアプリケーション自体) などの、トークンのサブジェクトが認可されているかどうかを判断します。

特定の sub または oid のクレームのいずれかに対してチェックします。

または、

サブジェクトが、roles、scp、groups、wids のクレームを持つ適切なロールまたはグループに属していることを確認できます。 たとえば、変更できないクレーム値 tid および oid を、アプリケーション データの結合キーとして使用し、ユーザーにアクセスを付与するかどうかを判断します。

roles、groups または wids クレームは、サブジェクトが操作を実行する認可を持っているかどうかを判断するためにも使用できますが、これらは、サブジェクトにアクセス許可を付与できるすべての方法を網羅した一覧ではありません。 たとえば、管理者が API に書き込むためのアクセス許可を持っていても、通常のユーザーではない場合や、ユーザーが何らかのアクションを実行できるグループに属している場合があります。 wid クレームは、Microsoft Entra 組み込みロールに存在するロールからユーザーに割り当てられたテナント全体のロールを示します。 詳細については、「Microsoft Entra 組み込みロール」を参照してください。

警告

email、preferred_username、unique_name のようなクレームを使用して、保存したり、アクセス トークン内のユーザーがデータにアクセスできるかどうかを判断したりしないでください。 これらのクレームは一意ではなく、テナント管理者または場合によってはユーザーが制御できるため、認可の決定には適していません。 これらは、表示目的でのみ使用可能です。 また、upn クレームは認可に使用しないでください。 UPN は一意ですが、ユーザー プリンシパルの有効期間中に頻繁に変更されるため、認可用としては信頼できません。

アクターを検証する

ユーザーに代わって動作するクライアント アプリケーション ("アクター" と呼ばれます) も認可されている必要があります。 scp クレーム (スコープ) を使用して、操作を実行するためのアクセス許可がアプリケーションにあることを検証します。 scp のアクセス許可は、ユーザーが実際に必要とするものに限定し、最小限の特権の原則に従う必要があります。

ただし、トークンに scp が存在しない発生があります。 次のシナリオでは、scp の要求がないことを確認する必要があります。

  • デーモン アプリ/アプリのみのアクセス許可
  • ID トークン

スコープとアクセス許可の詳細については、「Microsoft ID プラットフォームのスコープとアクセス許可」を参照してください。

Note

アプリケーションが、アプリ専用トークン (デーモン アプリなど、ユーザーなしでのアプリケーションからの要求) を処理し、個々のサービス プリンシパル ID ではなく、複数のテナント間で特定のアプリケーションを認可する場合があります。 その場合、appid クレーム (v1.0 トークンの場合) または azp クレーム (v2.0 トークンの場合) をサブジェクト認可に使用できます。 ただし、これらのクレームを使用する場合、アプリケーションは、idtyp の省略可能なクレームを検証して、トークンがアプリケーションに対して直接発行されたことを確認する必要があります。 委任されたユーザー トークンはアプリケーション以外のエンティティによって取得される可能性があるため、この方法で認可できるのは app の種類のトークンのみです。

次のステップ