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

[アーティクル]
10/25/2023

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

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

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

トークンに適切な対象ユーザーが指定されている。
トークンのテナント 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、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 プラットフォームのスコープとアクセス許可」を参照してください。