更新トークンが使用される理由
JWTについて読むと、存続期間の短いトークンと共に更新トークンを含めるのが一般的です。そのため、一般的には、15分間などの短期間持続する有効期間の短いトークンと、有効期限が切れたときにこのトークンを更新する更新トークンがあるようです。私の理解では、存続期間の短いトークンの有効期限が切れている場合、アプリは更新トークンが取り消されていないことを確認する必要があります（データベースを確認してください）。そうでない場合は、新しい短期トークンを発行します。私は、単一の有効期間の短いトークンがない理由を理解しようとしています。
Jwtトークンに、トークンを使用するユーザーのユーザー名が含まれており、1時間で期限切れになるとします。有効期限が切れた場合、アプリケーションサーバーはこのトークンを検証して、実際に有効期限が切れており、私が発行したトークンであることを確認できません。有効な場合は、（データベース内で）このユーザーがトークンを更新して更新できることを確認してください。これは本質的に更新トークンを持っていることと同じではありませんが、ユーザーが2ではなく1つのトークンしか持っていないので、少し単純ですか？更新トークンを使用する利点がわかりませんか？
私は、JWTと更新トークンを使用しているがOpenID Connectとは何の関係もない、独自の認証ソリューションを使用していると想定しています。
JWTトークンはステートレスであり、更新トークンは通常ステートフルです。
ステートフルトークンとステートレストークンの利点と欠点を確認する必要があります。
- ステートレストークンは、追加のDB/Service呼び出しなしで検証できます（そのため、検証がより速く/より簡単です）が、それらを取り消すことはできません（信頼できるログアウトはありません）。
- ステートフルトークンは取り消される可能性がありますが（信頼性の高いログアウト）、毎回DB/Service呼び出しを介して検証する必要があります（したがって低速です）。
存続期間の長いJWTトークンはセキュリティリスクの増加を構成します。トークンが盗まれた場合、攻撃ウィンドウは長くなります。
更新トークンと組み合わせると、真ん中のどこかでソリューションが得られます。検証が高速で、ログアウトの信頼性が高くなります。
使用されるトークン（クライアントとサーバー）に応じて、自動更新を実装できます。ただし、このような独自のソリューションでは、パフォーマンス上の理由から、必要に応じて検証キャッシュで単一のトークンを使用することができます。