私はトークンベースの認証にかなり慣れていません。カスタムの有効期限/トークン更新スキームの欠陥を見つけようとしています。
Express API で基本的な JWT 認証を設定しています。JWT の有効期限を 1 時間に設定しています。ただし、JWT は、トークンが発行された時刻を基準にしてトークンの有効期限をチェックします。API呼び出しが成功するたびに有効期限がリセットされることをお勧めします。ユーザーがアプリを 1 時間以上アクティブに使用している場合、トークンを更新するために再度ログインする必要はありません (そして、作業中のデータが失われる可能性があります)。
一方、トークンが 1 時間以上応答しない場合は、トークンを期限切れにしたいと考えています。
私は次のアプローチを思いつきました：
API リクエストが成功するたびに、新しい JWT を発行し、カスタム レスポンス ヘッダーで送信します。私のクライアント側コードは、この JWT 応答ヘッダーをチェックし、その値を新しいデフォルトの Authorization 要求ヘッダーとして使用する責任があります。したがって、ユーザーからの API 要求が 1 時間以上ない場合、トークンは期限切れになり、更新されません。ログインが必要になります。さらに、トークンの元の発行日 (ログイン認証のタイムスタンプ) が保存されるため、24 時間後にトークンの「ハード有効期限」が適用されます。
これはかなり簡単で、かなり安全に思えますが、私の JWT 調査ではこれに関する言及は見当たりませんでした。同じ目標を達成するためのより良い方法はありますか? このアプローチで主要なセキュリティ ホールを見逃していませんか?
更新: これについてしばらく考えた後、これの問題は、トークンの有効期限によって阻止できなかったリプレイ攻撃への扉を開くことであることに気付きました。したがって、絶対に「ハード有効期限」チェックが必要です。ハード有効期限は、最近のユーザー アクティビティに関係なく、発行日以降のある時点でトークンを無効にします。