User role changes from Admin to User. JWT still says Admin. What do you do?

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.

Strategy 1: Role version or token blacklist

Practical Solutions

1
Short-lived access tokens (5-15 min) + refresh token rotation: Revoke refresh token on role change, forcing new login or silent refresh.
2
Token blacklist (Redis): Store revoked token IDs (jti) with TTL equal to remaining token lifetime. Check blacklist on each request.
3
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.
4
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.
5
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.

Difficulty: 6/10

Topics: token revocation, role-based access control, session management

Scenario Questions

0-2 years experience

1
Suppose a user’s role is changed from Admin to User in the database, but the JWT they already have still contains the Admin role. How would you ensure the user’s permissions are updated immediately?
2
If you receive a request with a JWT that says the user is an Admin, but your user service reports the role is now User, what would your middleware do?

2-5 years experience

1
During a rollout you notice that after demoting several admins to regular users, those users can still access admin endpoints because their JWT still says Admin. Walk me through how you would debug and fix this issue.
2
Explain the trade‑offs between short‑lived access tokens with refresh tokens versus long‑lived JWTs when you need to revoke or change a user’s role quickly.
3
Your team wants to add a “role version” claim to the JWT to detect stale roles. How would you implement it and what edge cases would you watch for?

5-8 years experience

1
Design a system that can invalidate or update JWTs when a user’s role changes, without forcing every client to log out. Discuss the components, data flow, and any performance implications.
2
How would you handle role changes in a microservices architecture where some services cache user permissions locally? Describe your strategy to keep caches consistent.
3
Consider a high‑traffic API that validates JWTs on every request. What approach would you take to minimize latency while still ensuring revoked or changed roles are respected?

8+ years experience

1
At scale, your platform needs to support real‑time role revocation across dozens of services and regions. Propose an architecture that balances security, latency, and operational complexity.
2
Discuss the long‑term maintenance implications of embedding roles directly in JWTs versus referencing a central authorization service. Which would you choose for a multi‑tenant SaaS product and why?
3
Your organization is migrating from JWTs to opaque session tokens to simplify revocation. Outline a migration plan that minimizes disruption and ensures backward compatibility.

Follow-up Questions

❓What are the pros and cons of using a denylist versus short‑lived tokens?
❓How would you handle a situation where a compromised token is still valid?
❓Can you describe how you’d test your revocation mechanism?