ゼロ トラストのトークンを管理する

  • [アーティクル]

ゼロ トラストのためのアプリケーション開発では、アプリケーションの意図とそのリソース アクセス要件を具体的に定義することが重要です。 アプリケーションは、その意図される目的通りに機能するために必要なアクセスのみを要求しなければなりません。 この記事は、開発者として、Microsoft ID プラットフォームからアプリで受け取ることができる ID トークン、アクセス トークン、セキュリティ トークンを使ってアプリケーションにセキュリティを組み込むのに役立ちます。

開発するアプリケーションをゼロトラストの最小特権原則に適合させ、本来意図される目的を損なうような方法で使用されないようにします。 Just-In-Time & Just-Enoughアクセス (JIT/JEA)、リスクベースの適応型ポリシー、データ保護に基づいて、ユーザーのアクセスを制限します。 アプリケーション内の機密性が高い領域や影響力の強い領域を分離し、これらの領域へは承認されたユーザーのみがアクセスできるようにします。 アプリケーションを使用できるユーザーと、アプリケーション内で使用できる機能を制限します。

アプリケーションがMicrosoft ID プラットフォームから受け取る ID トークンを管理する方法に最小特権の原則を組み込むこと。 ID トークンに含まれる情報をチェックすることで、ユーザーが自ら主張する通りの人物であることを確認できるようにすること。 ユーザーまたは組織は、MFA を提供する、マネージド デバイスを使用する、正しい場所に存在する、などの認証条件を指定できます。

顧客がアプリケーションに対する承認を簡単に管理できるようにすること。 ユーザー プロビジョニングにかかる経費と必要な手動プロセスを軽減すること。 IT 管理者は、自動ユーザー プロビジョニングを使用することで、ターゲット ID ストア内でのユーザー ID の作成、維持、削除を自動化できます。 顧客は、Microsoft Entra ID でのアプリ プロビジョニングまたは HR 駆動型プロビジョニングを使用して、ユーザーとグループの変更に基づいた自動化を行うことができます。

アプリでトークン クレームを使用する

ID トークンでアプリケーション内のUX向けに提供されるクレームをデータベース内のキーとして使用し、クライアント アプリケーションへのアクセスを提供することができます。 ID トークンは、OpenID Connect (OIDC) が OAuth 2.0 に対して行うコア拡張機能です。 アプリケーションは、アクセス トークンと共に、またはアクセス トークンの代わりに ID トークンを受け取ることができます。

セキュリティ トークン承認の標準パターンでは、発行された ID トークンを使用して、アプリケーションがユーザーに関する情報を受け取ることができます。 リソースにアクセスするための承認プロセスとして ID トークンを使用しないでください。 ID トークンは承認サーバーによって発行され、ユーザーについての情報を伝えるクレームを含んでいます。

  • オーディエンス (aud) クレームは、アプリケーションのクライアント ID です。 API クライアント ID のトークンのみを受け入れること。
  • tid クレームは、トークンを発行したテナントの ID です。 oid クレームは、ユーザーを一意に識別するイミュ―タブル (不変) な値です。 データをユーザーに関連付ける必要がある場合は、キーとして tid クレームと oid クレームの一意の組み合わせを使用します。 これらのクレーム値を使用して、Microsoft Entra ID のユーザーの ID にデータを接続することができます。
  • sub クレームは 、ユーザーを一意に識別するイミュ―タブル (不変) な値です。 サブジェクトクレームは、アプリケーションに対しても一意です。 sub クレームを使用してデータをユーザーに関連付ける場合、そのデータをMicrosoft Entra ID 内のユーザーに接続することはできません。

openid スコープを使用して、アプリケーションから Microsoft ID プラットフォームに対して ID トークンを要求することができます。 OIDC 標準は、ID トークンの形式とコンテンツと共に openid スコープを管理します。 OIDC では、以下のスコープを指定します。

  • openid スコープを使用してユーザーをサインインさせ、sub クレームをID トークンに追加します。 これらのスコープはアプリとユーザーに固有のユーザー ID を提供し、UserInfo エンドポイントを呼び出します。
  • email スコープは、ユーザーの電子メール アドレスを含む email クレームを ID トークンに追加します。
  • profile スコープは、ユーザーの基本プロファイル属性 (名前、ユーザー名) を含むクレームを ID トークンに追加します。
  • offline_access スコープを使用すると、アプリケーションはユーザーが存在しない場合でもユーザー データにアクセスできます。

Microsoft Authentication Library (MSAL) は常に、openid、電子メール、profile スコープをすべてのトークン要求に追加します。 その結果、MSAL は常に、AcquireTokenSilent または AcquireTokenInteractive に対する呼び出しに対し、ID トークンとアクセス トークンを返します。 MSAL は常に offline_access スコープを要求します。 要求するアプリ側で offline_access スコープを指定していない場合でも、Microsoft ID プラットフォームは常に offline_access スコープを返します。

Microsoft は OAuth2 標準を使用してアクセス トークンを発行します。 ただし、OAuth2 標準では「トークンを受け取る」とのみ指定しており、トークンの形式やトークンに必要な条件は指定されていません。 アプリケーションが Microsoft Entra ID で保護されているリソースにアクセスする必要がある場合、リソースで定義されているスコープを使用する必要があります。

たとえば、Microsoft Graph は、アプリケーションが現在のユーザーの完全なユーザー プロファイルとテナント名にアクセスすることを許可する User.Read スコープを定義します。 Microsoft Graph では、その API で使用できる機能の全範囲にわたるアクセス許可を定義します。

承認時に、Microsoft ID プラットフォームはアプリケーションにアクセス トークンを返します。 リソースを呼び出すと、アプリケーションは API への HTTP 要求の承認ヘッダーの一部としてこのトークンを提供します。

トークンの有効期間を管理する

アプリケーションは、認証が Microsoft Entra ID で正常に完了した後に、ユーザーのセッションを作成できます。 ユーザー セッション管理により、ユーザーが再認証を必要とする頻度をコントロールします。 明示的に検証されたユーザーがアプリケーションから受けた認証を適切な特権および適切な期間で保持するのにユーザー セッション管理が果たす役割は非常に重要です。 セッションの有効期間は、ID トークン内の exp クレームに基づいている必要があります。 exp クレームは、その時刻を以てID トークンの有効期限が切れ、それ以降にはそのトークンを使用してユーザーを認証できなくなる時刻を示します。

アクセス トークンまたは ID トークン内の exp クレームに対してトークン応答内で指定されているトークンの有効期間に常に従うこと。 トークンの有効期間を管理する条件の中に、企業のサインイン頻度を含めることができます。 アプリケーション側でトークンの有効期間を設定することはできません。 トークンの有効期間を要求することもできません。

基本的に、トークンは有効かつ期限切れ時刻到達前である必要があります。 オーディエンスクレーム (aud) はクライアント ID と一致する必要があります。 トークンが信頼された発行者から提供されていることかどうかを確認すること。 マルチテナント API がある場合は、特定のテナントのみが API を呼び出せるようにフィルター処理することもできます。 トークンの有効期間に必ず従うこと。 nbf (有効期間開始時刻) クレームと exp (有効期間終了時刻) クレームをチェックし、現在の時刻がこれら 2 つのクレーム値内にあることを確認すること。

セッション有効期間を極端に長くまたは短く設定しないこと。 付与された ID トークンの有効期間 に従ってセッション有効時間を決めてください。 トークンの有効期間を超えてアプリのセッションをアクティブに保つことは、IT 管理者が未承認のアクセスを防ぐために定めるトークン有効期間管理ルール、ポリシー、懸念事項に違反する行為です。 また、セッション有効期間が短すぎるとユーザー エクスペリエンスが低下し、一方必ずしもセキュリティを向上させる効果はありません。 ASP.NET などの一般的なフレームワークでは、Microsoft Entra ID の ID トークンの有効期限からセッションと Cookie のタイムアウト時刻を設定できます。 ID プロバイダーのトークンの有効期限に従うことにより、ユーザーのセッショ時間が ID プロバイダーが指示するポリシーより長くならないようにします。

キャッシュと更新トークン

トークンを適切にキャッシュすることを忘れないでください。 MSAL はトークンを自動的にキャッシュしますが、トークンには有効期間があります。 有効期間全体でトークンを活用し、適切にキャッシュすること。 同じトークンを繰り返し要求すると、スロットリングによりアプリケーションの応答性が低下します。 アプリケーション側でトークンの発行を濫用すると場合、そのアプリケーションに新しいトークンを発行するのにかかる時間が長くなります。

MSAL ライブラリは、トークンの更新のしくみを含む OAuth2 プロトコルの詳細を管理します。 MSAL を使用しない場合は、選択したライブラリで更新トークンを効果的に使用するようにしてください。

クライアントは、保護されたリソースにアクセスするためのアクセス トークンを取得するときに更新トークンも併せて受け取ります。 現在のアクセス トークンの有効期限が切れたら、この更新トークンを使用して新しいアクセストークン／更新トークンのペアを取得します。 更新トークンは、他のリソースの追加のアクセス トークンを取得するのにも使用できます。 更新トークンは、ユーザーとクライアントの組み合わせに紐づけされています (リソースもしくはテナントには紐づけされていません)。 更新トークンを利用することで、そのアプリケーションがアクセス許可を持っているあらゆるリソースとクライアントの組み合わせに対してアクセス トークンを取得することができます。

トークンのエラーとバグを管理する

アプリケーション側で、アクセス トークンの内容の検証、デコード、検査、解釈、検査を行ってはなりません。 これらの操作は常にリソース API 側の責任となります。 アプリケーション側でアクセス トークンのコンテンツを調べようとすると、Microsoft ID プラットフォームが暗号化されたトークンを発行したときにアプリケーションが中断する可能性が非常に高くなります。

まれに、ネットワークやインフラストラクチャの障害、認証サービスの停止などの問題が原因で、トークンを取得するための呼び出しが失敗することがあります。 トークン取得エラーが発生した場合に次のベスト プラクティスに従うことで、アプリケーションの認証エクスペリエンスの回復性を向上させてください。

  • 暗号化を使用してトークンをローカルにキャッシュし、セキュリティを確保します。
  • セキュリティが確保されていないチャネルには、トークンなどのセキュリティアーティファクトを渡さないでください。
  • ID プロバイダーが提供する例外事項とサービス応答の内容を理解し、適切に対処すること。

開発者は多くの場合、リソースの呼び出しに対して 401 エラーを受け取った場合など、問題のデバッグのためにどうやってトークン内を調べたらよいか分からないことがあります。 暗号化が強化されたトークンではアクセス トークン内を調べることができなくなるため、アクセス トークン内を調べる代わりの手段を見つける必要があります。 デバッグの場合、アクセス トークンを含むトークン応答によって、必要な情報が提供されます。

コードの作成においては、個々のエラー ケースではなく、エラー クラスをチェックするようにすること。 たとえば、システムがアクセス許可を付与しない場合は、個々のエラーではなく、必要なユーザー操作を処理します。 これらの個々のケースを見逃す可能性があるため、個々のエラー コードを調べるのではなく、ユーザー操作のような分類子を確認することをお勧めします。

AcquireTokenInteractive にフォールバックし、AcquireTokenSilent 呼び出しに必要なクレーム チャレンジを提供する必要がある場合があります。 これにより、インタラクティブな要求の効果的な管理を保証します。

次のステップ