When a user's role changes (e.g., from Admin to User), any existing JWTs containing the old role must be invalidated to prevent unauthorized access. Solutions include using short-lived tokens with refresh token rotation, implementing a token blacklist, or embedding a version number in the JWT that is checked against a database.
JWTs are stateless and cannot be modified after issuance. If a user's role changes, existing tokens still carry the old role claim. To enforce the new permissions, you must either wait for the token to expire or actively revoke it. The recommended approach is to issue short-lived access tokens (e.g., 5–15 minutes) combined with refresh tokens. When the role changes, you can revoke the user's refresh token(s), forcing the client to re-authenticate to obtain a new access token with the updated role.
Short-lived access tokens (5-15 min) + refresh token rotation: Revoke refresh token on role change, forcing new login or silent refresh.
Token blacklist (Redis): Store revoked token IDs (jti) with TTL equal to remaining token lifetime. Check blacklist on each request.
Role version column: Store a role_version integer in user DB; include it in JWT. On each request, compare with DB value; if mismatch, reject.
Re‑fetch roles from DB on each request: Trade-off: adds DB call per request but allows instant role updates. Acceptable for low‑traffic services.
Combined approach: Short-lived token + refresh token revocation is most common in production (OAuth2 pattern).
The least invasive method is to keep access tokens short (minutes). When role changes, the client automatically gets a new token on next refresh cycle, picking up the new role. For immediate enforcement, use a blacklist or version check. Do not rely on long-lived tokens for permissions that can change frequently.
0-2 years experience
2-5 years experience
5-8 years experience
8+ years experience