トークン・クレームがデプロイメント・ポリシーと一致しないため、トークンの検証に失敗しました

APIゲートウェイ・サービスを使用してAPIゲートウェイおよびAPIデプロイメントを正常に作成し、APIのコール時にトークン検証クレームの不一致をトラブルシューティングする方法をご紹介します。

APIゲートウェイがトークン検証中にリクエストを拒否した場合、トークン・クレームがデプロイメントの認証ポリシーと一致しない可能性があります。トークンは存在し、適切に形成できますが、発行者、オーディエンス、有効期限または必要なカスタム・クレームがルート・ポリシーと一致しない場合でも、検証は失敗します。

問題の症状

次の症状が1つ以上表示される場合があります。

  • リクエストに適切にフォーマットされたトークンが含まれている場合でも、リクエストは認証中に拒否されます。
  • トークン・ペイロードはデコード後も有効ですが、APIゲートウェイは引き続きリクエストを拒否します。
  • 認証が失敗し、audissexpまたは必要なカスタム要求値に対する要求検証エラーが発生します。
  • 同じアプリケーションが1つのトークンで成功し、別の発行者、オーディエンスまたは環境からの別のトークンで失敗します。

考えられる理由

この問題には、次の1つ以上の原因が考えられます。

  • トークンのaudクレームが、デプロイメント用に構成されているオーディエンスと一致しません。
  • トークンのiss要求が構成された発行者と一致しません。
  • 認証ポリシーには、トークンにないカスタム・クレームが必要です。
  • 認証ポリシーには、トークンと一致しないカスタム・クレーム値が必要です。
  • トークンの有効期限が切れているか、トークン時間値が構成されたクロック・スキュー許容範囲外です。
  • 検出ベースまたはイントロスペクションベースの検証の場合、返される要求セットはデプロイメント・ポリシーを満たしません。

認証ポリシーの確認

リクエストを処理したルートの認証ポリシーを確認し、次の設定を確認します。

  • authentication.audiencesには、トークンが発行された対象者が含まれます。
  • authentication.issuersには、トークンを発行したアイデンティティ・プロバイダが含まれます。
  • verifyClaimsには、ルートが適用する必要がある要求および値のみが含まれます。
  • maxClockSkewInSecondsは、トークン発行者とリクエストを検証するシステムとの予想される時間差を考慮します。

障害が時間に関連している場合は、トークンのexp値を現在のUTC時間および構成済のクロック・スキュー許容値と比較します。

ログ・メッセージのレビュー

LoggingのAPIゲートウェイ実行ログで、失敗したリクエストを確認します。レスポンスからのリクエストIDを使用して、一致するログ・エントリを検索します。

次のような認証失敗イベントを探します。

  • jwtAuthentication.authenticationFailed
  • tokenAuthentication.authenticationFailed

次に、失敗した要求検証のログ・メッセージを確認します。メッセージは、ポリシーを満たさなかった要求または値を識別できます。

  • Validation failed for 'exp' claim.
  • JWT token not issued by the configured issuers.
  • JWT token not issued for the configured audience.
  • JWT token missing required claim '<claim>'.
  • JWT token does not have the expected claim value for '<claim>'.

トークンのクレームの検証

トークン・タイプに一致する検証メソッドを使用します。

JSON Web Token (JWT)の場合は、ペイロードをデコードし、関連するクレームをデプロイメント構成と比較します。audissexpおよび必要なカスタム要求値を確認します。

import base64
import json

token = "<paste-jwt-here>"
payload = token.split(".")[1]
payload += "=" * (-len(payload) % 4)
print(json.dumps(json.loads(base64.urlsafe_b64decode(payload)), indent=2))

不透明なトークンの場合は、構成されたイントロスペクション・エンドポイントを直接コールします。戻されたaudissexpおよびカスタム・クレーム値をAPIゲートウェイ・デプロイメント・ポリシーと比較します。

curl -sS -u "<client-id>:<client-secret>" \
 -H "Content-Type: application/x-www-form-urlencoded" \
 -d "token=<paste-token-here>" \
 "https://<identity-provider>/oauth2/v1/introspect"

失敗したリクエストを処理した正確なデプロイメントおよびルート構成に対してトークンを検証します。

クレームの不一致を修正

失敗した検証チェックに一致する修正を適用します。

  • オーディエンスが間違っている場合は、authentication.audiencesを更新するか、予期されるオーディエンスに対して発行されたトークンを使用します。
  • 発行者が間違っている場合は、authentication.issuersを更新するか、予期されるアイデンティティ・プロバイダのトークンを使用します。
  • 必要なカスタム要求がない場合は、トークン発行プロセスを更新するか、verifyClaimsを意図した要件と一致するように更新します。
  • 必要なカスタム・クレームの値が間違っている場合は、トークン・クレーム値を修正するか、verifyClaimsで必要な値を更新します。
  • トークンの有効期限が切れている場合は、有効なトークンを使用してリクエストを再試行してください。
  • クロック・スキューが原因で障害が発生した場合、maxClockSkewInSecondsを調整するのは、セキュリティ要件に対して時間差が予想され許容される場合のみです。

トークンの検証

ポリシーを更新するか、修正されたトークンでリクエストを再試行した後、結果を確認します:

  • 同じ要求を再度送信します。
  • デプロイメントがリクエストを受け入れることを確認します。
  • 要求検証の失敗が実行ログに表示されなくなったことを確認します。

詳細情報

詳細は、次を参照してください: