• iat
  • issued at time
  • invalid-iat
  • invalid issued at time
  • id token

"iat" トークンクレームの重要性と"Invalid issued at time"エラーのトラブルシューティングの理解

この投稿では、ID トークンの"iat"クレームの重要性と"Invalid issued at time in ID token"エラーをトラブルシュートする方法を探ります。

Charles
Charles
Developer

"iat" トークンクレームの重要性と"Invalid issued at time"エラーのトラブルシューティングの理解

背景

コミュニティでは、時折、"ID トークンの無効な発行時刻"という頭を悩ます問題についてユーザーから聞くことがあります。ユーザーは「昨日は動作していたのに、突然今日動かなくなった」や「このコンピューターでは動作するが、他のコンピューターでは動かない」と不満を漏らします。

この投稿では、Logto でこの問題がなぜ発生するのかを探り、それに対応するためのノウハウを提供します。

はじめに

OAuth 2.0 と OpenID Connect (OIDC) では、ID トークンが、安全にユーザーの身元情報を当事者間で伝達する上で重要な役割を果たします。ID トークンのクレームのひとつに "iat" (issued-at-time) と呼ばれるものがあります。これは、ID トークンが認可サーバーによって発行されたタイムスタンプを表しています。

では、なぜ "iat" クレームが重要なのでしょうか?

  1. トークンの新鮮さと有効期限: "iat" クレームは、ID トークンの新鮮さを評価するための重要な情報を提供します。"iat" タイムスタンプを現在時刻と比較することで、依拠するパーティはトークンが最近発行されたかどうかを判断できます。これは、最新の身元情報を使用する必要があるアプリケーションにとって、貴重な情報です。
  2. リプレイ攻撃の軽減: "iat" クレームは、リプレイ攻撃を軽減する上で重要な役割を果たします。リプレイ攻撃では、攻撃者が以前にインターセプトされたトークンを再利用しようと試みます。"iat" クレームはトークンの年齢の許容ウィンドウを設定することで、そのような攻撃を検出するのに役立ちます。このウィンドウ外のトークンは無効と見なされます。
  3. トークン使用ポリシーの強制: アプリケーションはしばしば、セキュリティ上の理由から、ID トークンの最大許容年齢に関するポリシーを課します。"iat" クレームは、トークンの使用が指定された期間内であることを依拠するパーティが確保するのに役立ちます。これにより、古いトークンの使用に関連するリスクを最小限に抑えることができます。
  4. トークンの取り消しのサポート: 一部のシナリオでは、認可サーバーは発行されたトークンを取り消す必要があるかもしれません。"iat" クレームは、トークンの発行時刻を明確に示すことで、トークンの取り消しプロセスに役立ちます。これにより、発行時刻に基づいて特定のトークンの識別および取り消しが簡素化されます。

"iat" クレームを扱う際のベストプラクティス

  • "iat" クレームを検証する: 依拠するパーティは常に "iat" クレームを検証して、それが許容範囲内にあることを確認する必要があります。この範囲は、アプリケーションの特定のセキュリティ要件によって異なる場合があります。
  • クロックスキューを考慮する: 現在時刻と "iat" タイムスタンプを比較する際、クロックスキューのある程度を許容するようにします。クロックスキューは、認可サーバーと依拠するパーティ間の潜在的な時刻の違いを考慮に入れます。
  • トークン有効期限ポリシーを設定する: "iat" クレームを "exp" (有効期限) クレームと組み合わせて利用し、包括的なトークン使用ポリシーを強制し、アプリケーションの全体的なセキュリティ体制を向上させます。

トラブルシューティング

さて、悪名高い "Invalid issued at time" エラーの根本原因は、ほぼ明らかです。

リプレイ攻撃を軽減し、クロックスキューを考慮するために、Logto は以前、ID トークンに60秒の許容ウィンドウを設定していました。世界時刻との差が60秒を超える依拠しているパーティは、潜在的にリスクがあると見なされ、ID トークンの検証に失敗します。したがって、"Invalid token at time" エラーです。

しかし、実際の世界では、クロックスキューは発生します。時にはコンピューターが世界時刻サーバーに接続してコンピューターの時間を同期できなくなります。時には、認可サーバーが同期していないこともあります。さらに言えば、両方が同期していない場合もあります。

さらに、SSO シナリオでは、さまざまなクライアントと SSO プロバイダー間の時刻の違いがさらに大きくなる可能性があります。

ソリューション

痛みを軽減し、安全対策を考慮するために、Logto は iat の許容を非 SSO 認証では60秒から5分に、SSO シナリオでは10分に増加させました。

その間にも、https://time.is という便利なツールサイトを使用して、コンピューターの時刻が世界と同期しているかどうかを確認できます。手動で時刻を同期または別の時刻サーバーに変更し、時差が常に許容ウィンドウ内に収まるようにします。

結論

ID トークンの "iat" クレームは、現代のアプリケーションにおけるアイデンティティとアクセス管理のセキュリティを高めるための重要な要素です。"iat" クレームを扱う際にベストプラクティスを取り入れることで、堅牢で安全なアイデンティティ認証プロセスを保証します。

また、コンピューターの時刻が常に世界時刻サーバーと同期していることを確認してください。