JWTの有効期限とJWTペイロードの更新の処理

Question

私は個人用/趣味用のアプリケーション用のKoaベースのNode.jsバックエンドを持っています。

私はJWTトークンでセッション処理を実装しました。クライアント（AngularJS）は、成功したログイン後にトークンを取得し、トークンをどこかに格納します（現在はsessionStorageにありますが、この質問の目的には関係ありません）。私はJWTが言う、ユーザーはので、私は彼の電話番号を提供するために、彼に尋ねた、私が好きな2FAオン表し、ユーザレコードを更新する必要がある場合

1. ：

   は、私は2つの質問がありますこの電話番号をユーザーのレコードに設定します。現在、電話番号の検証が成功した後、バックエンドに電話してユーザーレコードを更新し、更新されたユーザーレコードで新しいJWTトークンを作成します（ハッシュされたパスワードのようにJWTトークンから機密情報を除外しますが、クライアント側の使用のための電話番号を含める）。いくつかの資格証明が変更され、この新しいトークンで既存のクライアント側トークンを更新するときに、新しいトークンを作成することはできますか？別のトークンを作成することは決してありません。認証を成功させた場合にのみ作成してください。トークンのペイロードを更新する方法は？

2. 期限切れのJWTトークンをどのように処理すればよいですか？私の考えでは、3つの（可能な）シナリオがあります：

   2.1。 JWTは短命、例えば15分と設定されています。バックエンドサーバーが401 Unauthenticated '無効なトークン'（これはデフォルト動作のkoa-jwtだと思います）を返信すると、クライアントが自動的にログアウトして再認証が必要になります。しかし、私はまた、更新された有効期限を持つトークンを再作成するバックエンドのチェーンの最後の補完的なミドルウェアをセットアップし、クライアントは既存のトークンを最新のものに置き換えます。したがって、ユーザーがアクティブで、保護されたAPI呼び出しごとにアプリケーションを使用する場合、成功した場合は、古いトークンを置き換える新しいトークンを作成します。

   2.2。 JWTは長期生存期間、例えば1週間と設定され、期限が切れた場合は、クライアントからの再認証を選択します。

   2.3。コピーhttps://tools.ietf.org/html/rfc6749#section-1.5。ここでは、認証に成功した後にJWTトークンを作成するときに、access_tokenとrefresh_tokenを送信します。 access_tokenが期限切れになり、サーバーがHTTP 401 '無効なトークン'（koa-jwtの既定値）で応答すると、クライアントはrefresh_tokenをバックエンドに送信して新しいaccess_token（およびオプションで新しいrefresh_token）を要求します。この場合、新しいトークンを提供するためにrefresh_tokenが古いaccess_tokenに対してどのように検証されているかを完全に理解していませんか？または、なぜrefresh_tokenを必要とするのでしょうか？

上位トピック（JWTの更新とJWTの有効期限）に関する一般的なアドバイスは参考になります。

Answer 1

最初の質問に回答する前に、2番目の質問にお答えしたいと思います。

基本的に言及した3番目のオプションは、アクセストークンを更新するための最良の方法です。アクセストークンは短い生存時間（約5分）でなければならず、リフレッシュトークンの寿命は長くなります。アクセストークンが期限切れになったら、リフレッシュトークンをバックエンドに送信し、新しいアクセストークンを取得します。だからあなたの応答は次のようなものでなければなりません：

{ 
"token_type":"bearer", 
"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiVlx1MDAxNcKbwoNUwoonbFPCu8KhwrYiLCJpYXQiOjE0NDQyNjI4NjYsImV4cCI6MTQ0NDI2Mjg4Nn0.Dww7TC-d0teDAgsmKHw7bhF2THNichsE6rVJq9xu_2s", 
"expires_in":10, 
"refresh_token":"7fd15938c823cf58e78019bea2af142f9449696b" 
} 

だから、アイデアは（アクセストークン/リフレッシュトークンを生成します）認証サーバー&リソースサーバ（アクセストークンを検証し、リソースへのアクセス）にあなたのアプリケーションを区切ることです。 Authorization Serverのアクセス・トークンに対してリフレッシュ・トークンを検証するためにスキーマを維持することができます。このリンクに記載されているスキーマのセクションを参考にしてください。 Oauth2。必要に応じてスキーマを変更できます。要求トークンごとにアクセストークンとともに更新トークンを送信する必要はありません。リフレッシュ・トークンは、新しいアクセス・トークンを生成するためにのみAuthorizationサーバーに送信することができます。リフレッシュトークンを生成する方法は？ Javaを使用している場合は、UUID.randomUUID()を使用して一意のリフレッシュトークンを生成します。

最初の質問に答えるには、更新されたユーザーレコードに基づいてJWTペイロードを更新する場合は、同じ更新トークンを使用して、更新されたペイロードで新しいアクセストークンを生成します。電話番号がユーザーレコードに存在する場合はペイロードに追加され、そうでない場合はペイロードにヌルになるため、ロジックは変わりません。

リフレッシュトークンを使用する主な利点は、アクセストークンは、下からのリフレッシュトークン

Answer 2

を使用していつでも更新することができるということである私は、彼らはここであなたを助けるとは思わないよう、私はリフレッシュトークンを無視し。一般的に、クライアントアプリケーションは、ネイティブモバイルアプリケーションやサーバーサイドWebアプリケーションと考えると、ユーザーのブラウザよりも安全なストレージを提供できる他のシナリオを目指しています。

リフレッシュトークンは、長寿命ですです。これは、クライアントがサーバーから1つを取得したときに、潜在的な攻撃者がこのトークンを使用しないようにするために、このトークンを安全に保管する必要があることを意味します。このため、ブラウザに格納することは安全ではありません。

（強調は私です、ソースrefresh tokens）

これはオプション2.3悪いオプションされていない、基本的には2.2と同じであることを意味します。長いセッション時間を持つWebアプリケーションを持つことは珍しいことではありません。アプリケーションの機密性が高くない場合は、長いセッションを使用してユーザーエクスペリエンスを向上させることは許容されます。たとえば、Djangoでは、セッションクッキーの経過時間にデフォルトの2週間を使用します。 SESSION_COOKIE_AGEを参照してください。

残りのオプション（2.1）は、通常、スライドセッションと呼ばれます。セッションタイムアウトは短いですが、ユーザーがその間隔内でアプリケーションを使用し続ける限り、セッションは自動的に更新されます。これはおそらく最も一般的なアプローチであり、少なくとも私がほとんどの時間を費やしたアプローチなので、偏っています。私が留意する唯一のことは、スライディングセッションは、通常、クライアントサイドをクッキーとして保存し、次にサーバーに格納された実際のセッションデータで隠されたセッション識別子で実装されることです。

ブラウザのローカルストレージに保存されているステートレスJWTトークン（実際のユーザーデータを含む）があるため、アプローチは少し異なります。あなたが言ったように、トークンを更新するには、新しい署名を生成する必要があるため、新しいトークンを生成する必要があります。

署名は、JWTの送信者は、それはそれはで、メッセージが途中で変更されていなかったことを確認するために言う人であることを確認するために使用されます。

（強調は私です;ソースJSON web tokens）

すべてのことを言って、私は次の点を考慮します：

1. あなたが本当にJWTのか、定期的なセッション識別子として保存されている場合が必要な場合は、自問してみてくださいクッキー（HTTP Only）はあなたのロジックを単純化します。
2. たとえば、JWTが要件である場合、これらのトークンを認証として受け入れる別のAPIがある場合、ブラウザベースアプリケーションのリフレッシュトークンは推奨されないため、オプション2.1または2.2を検討します。

JWTは巨大ではないと考えるべきですが、自動的に更新することを決定した場合でもオーバーヘッドになります。セッションの継続時間を20分に設定することでこれを少し軽減し、セッションの半分が経過した後にのみ自動更新を実行することができます。

もう一つのポイントは、注入されたスクリプトがlocalStorage/sessionStorageから読み取ることができるだろうとして、アプリケーションのXSSのような脆弱性が攻撃者にアクセストークンを公開することで、これはHTTPのみセッションCookieの保存を支持して別のポイントになることができます。