关于Access Token与Refresh Token存储方式及加密的技术问询

Great question—you’re already thinking along the right lines with your token expiration timelines and initial storage plan! Let’s break this down to confirm your approach and add some key details:

• Access Token in localStorage/sessionStorage: This is a standard choice for client-side API access, since you need straightforward access to attach it to request headers (like Authorization: Bearer <token>). The main caveat here is XSS vulnerability—if malicious script slips into your app, an attacker can steal the token. Mitigate this with strict XSS defenses: sanitize all user input, enforce a tight Content Security Policy (CSP), and avoid risky DOM operations like innerHTML.
• Refresh Token as an httpOnly Cookie: This is the industry best practice for protecting refresh tokens from XSS. Since httpOnly cookies are inaccessible to JavaScript, even an XSS exploit can’t siphon this token. Just make sure you pair this with the Secure flag (so it only travels over HTTPS) and SameSite flag (preferably Strict or Lax) to block CSRF attacks.

Short answer: Yes, but it depends on where the token lives:

• Stored on your backend: If you save refresh tokens in a database, always encrypt them at rest. Use a strong authenticated encryption method like AES-GCM—this way, even if an attacker gains database access, they can’t use the encrypted tokens without your decryption key.
• Sent to the client: You don’t need to encrypt the token itself before sending it in the httpOnly cookie, because HTTPS already encrypts it in transit. The Secure flag ensures it never travels over unencrypted HTTP, which is the key protection here.

• Add CSRF protection for refresh endpoints: Since refresh tokens live in cookies, your token-refresh endpoint is exposed to CSRF attacks. Fix this by generating a CSRF token (store it in localStorage), sending it in a custom header like X-CSRF-Token when requesting a new access token, and validating it on the backend.
• Stick to short-lived Access Tokens: Your 20-minute window is ideal—this minimizes the damage if an access token is stolen. Avoid extending this beyond 1 hour as you planned.
• Implement refresh token rotation: Every time a user refreshes their access token, issue a new refresh token and invalidate the old one. This limits the lifespan of any stolen refresh token, even if it’s httpOnly.
• Build a revocation mechanism: Add a logout endpoint (or a token revocation API) that invalidates refresh tokens in your database. This lets users immediately kill their sessions if they suspect a breach.

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