JWT更新トークンフロー
私はモバイルアプリを作成しており、認証にJWTを使用しています。
これを行う最良の方法は、JWTアクセストークンとリフレッシュトークンをペアにして、アクセストークンを必要な頻度で期限切れにすることです。
- 更新トークンはどのように見えますか？ランダムな文字列ですか？その文字列は暗号化されていますか？別のJWTですか？
- 更新トークンは、アクセスのためにユーザーモデルのデータベースに格納されますか？この場合、暗号化する必要があるようです
- ユーザーがログインした後にリフレッシュトークンを送り返し、クライアントに別のルートにアクセスしてアクセストークンを取得させますか？
JWTとリフレッシュトークンに関するものであるため、これはOAuth 2.0であると仮定します...：
原則として、アクセストークンと同様に、リフレッシュトークンは、説明するすべてのオプションを含む任意のものです。 JWTは、承認サーバーがステートレスになりたい場合、またはそれを提示するクライアントに何らかの「所有権の証明」セマンティクスを適用する場合に使用できます。リフレッシュトークンはアクセストークンとは異なり、リソースサーバーに提示されるのではなく、最初にそれを発行した承認サーバーにのみ提示されるため、JWT-as-access-tokensの自己完結型の検証最適化は更新トークンを保持しません
データベースのセキュリティ/アクセスに依存します。他の関係者/サーバー/アプリケーション/ユーザーがデータベースにアクセスできる場合は、はい（ただし、暗号化キーを保存する場所と方法によって燃費は異なる場合があります...）
承認サーバーは、アクセストークンとリフレッシュトークンの両方を同時に発行できます。これは、クライアントがトークンを取得するために使用する許可に応じて異なります。仕様には、標準化された各助成金の詳細とオプションが含まれています
これに基づいて リフレッシュトークンを使用したJWTのNode.jsによる実装 ：
1）この場合、ユーザーはuidを使用しますが、これはJWTではありません。トークンを更新すると、更新トークンとユーザーが送信されます。 JWTとして実装する場合、JWT内にあるため、ユーザーを送信する必要はありません。
2）個別のドキュメント（テーブル）でこれを実装します。ユーザーはさまざまなクライアントアプリケーションにログインでき、アプリごとに更新トークンを持つことができるため、私には理にかなっています。ユーザーが1つのアプリがインストールされているデバイスを紛失した場合、そのデバイスの更新トークンは、ログインしている他のデバイスに影響を与えることなく無効になります。
3）この実装では、アクセストークンとリフレッシュトークンの両方でログインメソッドに応答します。それは私にとって正しい縫い目です。
JWTアクセストークンを取り消す手順は次のとおりです。
1）ログインするときに、クライアントに応答して2つのトークン（アクセストークン、更新トークン）を送信します。
2）アクセストークンの有効期限は短くなり、リフレッシュの有効期限は長くなります。
3）クライアント（フロントエンド）は、ローカルストレージにリフレッシュトークンを保存し、Cookieにアクセストークンを保存します。
4）クライアントは、APIの呼び出しにアクセストークンを使用します。ただし、有効期限が切れたら、ローカルストレージから更新トークンを選択し、認証サーバーAPIを呼び出して新しいトークンを取得します。
5）認証サーバーには、更新トークンを受け入れ、その有効性をチェックして新しいアクセストークンを返すAPIが公開されます。
6）更新トークンの有効期限が切れると、ユーザーはログアウトされます。
詳細が必要な場合はお知らせください。コード（Java + Springブート）も共有できます。
ご質問：
Que 1：長い有効期限で追加されたクレームの少ない別のJWTです。
質問2：データベースにはありません。バックエンドはどこにも保存しません。彼らは単に秘密/公開鍵でトークンを解読し、有効期限でも検証します。
Que3：はい、正しい