次の方法で共有

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

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

アプリケーションが 最小限の特権 のゼロ トラスト原則に準拠し、意図を損なう方法で使用を防ぐことを確認します。 ジャスト・イン・タイムおよびジャスト・エナフ・アクセス（JIT/JEA）、リスクベースのアダプティブ・ポリシー、データ保護により、ユーザー・アクセスを制限します。 アプリの機密性の高い強力なセクションを分離します。 これらの領域への承認されたユーザー アクセスのみを提供します。 アプリケーションを使用できるユーザーと、アプリに含まれる機能を制限します。

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

顧客がアプリの承認を簡単に管理できるようにする。 ユーザーの作成と構成のオーバーヘッドと手動プロセスを減らします。 自動ユーザー プロビジョニング を使用すると、IT 管理者はターゲット ID ストアでのユーザー ID の作成、メンテナンス、削除を自動化できます。 顧客は、Microsoft Entra ID での アプリ プロビジョニング または HR 駆動型プロビジョニング を使用して、ユーザーとグループへの変更に基づいて自動化を行うことができます。

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

ID トークンのクレームを、アプリケーション内のユーザーエクスペリエンスを向上させるために、データベースのキーとして使用します。 クライアント アプリケーションへのアクセスを提供します。 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 トークンの有効期限からセッションと Cookie のタイムアウトを設定できます。 ID プロバイダーのトークンの有効期限に従って、ユーザーのセッションが ID プロバイダーが指示するポリシーを超えないことを確認します。

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

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

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

クライアントは、保護されたリソースにアクセスするためのアクセス トークンを取得すると、更新トークンを受け取ります。 更新トークンを使用して、現在のアクセス トークンの有効期限が切れた後に新しいアクセス トークンと更新トークンのペアを取得します。 更新トークンを使用して、他のリソースの追加のアクセス トークンを取得します。 更新トークンは、(リソースまたはテナントではなく) ユーザーとクライアントの組み合わせにバインドされます。 更新トークンを使用すると、アプリにアクセス許可があるリソースとテナントの任意の組み合わせでアクセス トークンを取得できます。

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

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

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

  • 暗号化を使用してトークンをローカルにキャッシュし、セキュリティで保護します。
  • セキュリティで保護されていないチャネルでは、トークンなどのセキュリティ成果物を渡さないでください。
  • ID プロバイダーからの例外とサービス応答を理解し、対処します。

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

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

場合によっては、 AcquireTokenInteractive にフォールバックし、 AcquireTokenSilent 呼び出しに必要な要求チャレンジを提供する必要があります。 これにより、対話型要求の効果的な管理が保証されます。

次のステップ

  • Last updated on