刷新令牌验证流程、存储声明及新Bearer令牌签发安全校验咨询

Hey Greg, let's dive into your refresh token setup for your SPA—you're already on the right track, but there are a few key tweaks and security checks to add to harden things up.

What Claims Should a Refresh Token Include? #

Your current exp (expiration) and username claims are a solid start, but you should expand these to make the token more secure and usable:

• jti (JWT ID): A unique, random identifier for each refresh token. This is critical for revocation—instead of tracking usernames, you can track individual token IDs, which lets you revoke specific tokens without invalidating all of a user's sessions.
• sub (Subject): Use a persistent user ID (like a database UUID) instead of just username. Usernames can be changed, but a user ID stays consistent, avoiding issues if a user updates their username while their refresh token is still valid.
• iss (Issuer): The URL/identifier of your authorization server. This ensures the refresh token was issued by your trusted system, not a malicious third party.
• aud (Audience): The identifier for your SPA (e.g., https://your-spa.com). This prevents the token from being used by other applications that might share your auth server.
• iat (Issued At): The timestamp when the refresh token was created. Useful for auditing, and can help detect suspiciously old tokens that might have been stolen.

Also, a quick note: Since refresh tokens are highly sensitive (they can get new access tokens indefinitely until revoked), consider using JWE (JSON Web Encryption) instead of JWS for your refresh tokens. JWE encrypts the payload so even if the token is intercepted, the attacker can't read the claims inside.

Validating Refresh Tokens & Issuing New Access Tokens: Complete Steps #

Your current workflow covers the basics, but you're missing several critical security checks. Here's the full, secure process:

1. Parse and verify the token's integrity: If using JWS, validate the signature with your auth server's public key. If using JWE, decrypt it first using your private key. Reject any tokens that fail this check—they could be tampered with or forged.
2. Check exp claim: Confirm the token hasn't expired, just like you're already doing.
3. Validate iss and aud claims: Ensure the issuer matches your auth server and the audience matches your SPA's identifier. This blocks tokens issued for other apps or malicious servers.
4. Verify the user exists: Look up the user associated with sub (or username) in your database. If the user has been deleted or deactivated, reject the refresh request.
5. Check if the token is revoked: Use the jti to query your revocation list (a database table or cache) to see if this specific token has been marked as revoked. Your current step checks revocation, but tying it to jti is more precise than just username.
6. Optional: Validate device consistency: If your SPA tracks device fingerprints (e.g., a hash of the user's browser/device info), include a device_id claim in the refresh token. Compare this to the device fingerprint sent with the refresh request to prevent stolen tokens from being used on other devices.
7. Enforce rate limiting: Add rate limits to your refresh endpoint (e.g., 5 requests per minute per user) to block brute-force attacks or abuse.
8. Issue a new short-lived access token: Generate a new JWT access token with the user's claims, set a short expiration (e.g., 15-30 minutes), and return it (along with a new refresh token if you're using rotating refresh tokens—more on that below).

Is Your Current Flow Correct? What's Missing? #

Your core workflow is on the right path, but you're missing these key security checks:

• Token integrity verification: You didn't mention validating the refresh token's signature (if JWS) or decrypting it (if JWE). Skipping this means an attacker could forge a refresh token with a valid exp and username and get new access tokens.
• Issuer/audience validation: Without checking iss and aud, a token issued for another application could be used to get access tokens for your SPA.
• User existence check: If a user is deleted, their refresh token would still work if you don't verify they're still active in your system.
• Precise revocation tracking: Using just username means revoking one token would require invalidating all of a user's refresh tokens. Using jti lets you revoke individual tokens (e.g., if a user logs out on one device).

Also, consider implementing rotating refresh tokens: Every time you issue a new access token, issue a new refresh token and invalidate the old one. This limits the window of opportunity if a refresh token is stolen—once the user refreshes, the old token is no longer valid.

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