JWT令牌实践技术问询：用户修改密码时是否需更新Refresh Token？无数据库存储Refresh Token如何实现令牌失效？

Great questions—these are both key considerations for keeping your authentication setup secure while leveraging JWT's strengths. Let's break them down one by one.

1. Should I regenerate the Refresh Token when a user changes their password? #

Absolutely yes, and here's why:

• Changing a password is a clear signal that the user wants to invalidate any existing sessions they don't trust (e.g., old devices, shared computers, or potentially compromised sessions). If you don't replace the Refresh Token, an attacker who stole the old token could still use it to get new Access Tokens, making the password change pointless.
• What to do in practice:
  • After successfully updating the user's password, immediately invalidate the old Refresh Token (we'll cover how to do this for your setup in the next section).
  • Issue a new Refresh Token via an Http-only Cookie, just like you did during the initial login.
  • Have your frontend clear the existing Access Token from Vuex, then use the new Refresh Token to fetch a fresh Access Token to resume the user's session on their current device.

2. How to invalidate existing Refresh Tokens without storing them in a database? #

You're right that JWT's stateless nature means you can't natively revoke tokens before their expiration—but there are practical workarounds that balance JWT's benefits with the need to revoke tokens when needed. Here are your best options:

Option 1: Shorten Refresh Token expiration + sliding refresh #

• Core idea: Keep your Refresh Token's TTL (time-to-live) relatively short—think 1 to 7 days instead of weeks or months. This limits the window where a stolen token can be misused.
• Pair with sliding refresh: Every time a user uses a valid Refresh Token to get a new Access Token, issue a new Refresh Token with a fresh expiration. This way, active users get their session automatically extended, while inactive users' tokens expire quickly.
• Pros: No database required, simple to implement.
• Cons: Still can't instantly revoke tokens, but reduces risk significantly.

Option 2: Add a "revocation marker" to the Refresh Token payload #

Embed a small, verifiable value in your Refresh Token's payload that you can update when you need to revoke old tokens. Two common approaches:

• Version number: Include a version claim (e.g., "v": 1) in the Refresh Token. Store the current version for each user in your database. When you need to revoke tokens (like after a password change), increment the user's version number. When validating a Refresh Token, compare the payload's v value to the user's current version in the database—if they don't match, reject the token.
• Password hash: Include a hash of the user's current password in the Refresh Token payload. When the user changes their password, the hash changes. During validation, compute the hash of the user's current password and compare it to the one in the token—if they don't match, reject the token.
• Example payload:

  {
    "sub": "user123",
    "exp": 1735689600,
    "v": 2,
    "pwd_hash": "a1b2c3d4..."
  }
  

• Pros: Avoids storing full Refresh Tokens in the database—only a small value per user. Keeps most of JWT's stateless benefits.
• Cons: Requires a quick database lookup during token validation, but it's a tiny query that won't impact performance.

Option 3: Use a token blacklist (with Redis for speed) #

If you need instant revocation, a blacklist is the most direct solution. Here's how it works:

• When you need to invalidate a token (e.g., password change, user logs out of all devices), add the Refresh Token's unique identifier (or the token itself) to a blacklist stored in a fast in-memory store like Redis. Set the blacklist entry's expiration to match the token's original TTL.
• During Refresh Token validation, first check if the token is in the blacklist. If it is, reject it immediately.
• Pros: Allows instant revocation of specific tokens.
• Cons: Requires maintaining a blacklist, but Redis is lightweight and designed for this kind of quick lookups. It's a small trade-off for the security benefit.

Option 4: Frontend-side session invalidation (for active devices) #

For users who are currently logged in on other devices, you can use real-time communication (like WebSockets) to send a "session invalidated" signal. When the frontend receives this, it clears the Access Token from Vuex and redirects to the login page.

• Note: This only works for devices that are online. Offline devices will still have valid tokens until they expire, so pair this with one of the above options for full coverage.

内容的提问来源于stack exchange，提问作者Habebit