基于角色授权的JWT应用：用户信息变更处理方案探讨

Hey there, let's break down practical solutions for your scenario—you're building a Spring Security app with JWT, trying to balance performance (avoiding DB hits on every request) and handling immediate changes to user roles/passwords. Your current short-lived token approach works but has a delay, so here are other robust methods:

First, let's recap your context (for clarity) #

You're working on a Spring Security app that needs:

• Role-based URI access control
• Password modification functionality
• Admin ability to update other users' roles

You noticed that the tutorial's approach of loading UserDetails from the DB on every request (via CustomUserDetailsService in the filter) hits performance:

public class JwtAuthenticationFilter extends OncePerRequestFilter { 
    //... 
    @Override 
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { 
        try { 
            String jwt = getJwtFromRequest(request); 
            if (StringUtils.hasText(jwt) && tokenProvider.validateToken(jwt)) { 
                Long userId = tokenProvider.getUserIdFromJWT(jwt); 
                UserDetails userDetails = customUserDetailsService.loadUserById(userId); 
                UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities()); 
                authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(request)); 
                SecurityContextHolder.getContext().setAuthentication(authentication); 
            } 
        } catch (Exception ex) { 
            logger.error("Could not set user authentication in security context", ex); 
        } 
        filterChain.doFilter(request, response); 
    } 
    //... 
}

The tutorial author offered an alternative:

You can also encode the username and roles into JWT claims and create the UserDetails object by parsing these claims.

But you correctly pointed out a major flaw: without tracking issued tokens, you can't revoke them, so role changes won't take effect until existing tokens expire.

Your workaround is to use short-lived tokens (15 mins) that refresh with updated user info from the DB once expired. While simple, this means role/password changes have a delay before they're enforced.

Alternative Solutions for Immediate or Near-Immediate User Info Updates #

1. Token Blacklist with Redis #

Implement a real-time token blacklist to invalidate tokens instantly when user info changes:

• When a user's password is updated, their role is changed, or they log out, add their active JWTs to the blacklist.
• In your JwtAuthenticationFilter, after validating the token's signature and expiration, check if it's in the blacklist. If yes, reject the request.
• Use Redis for the blacklist: store tokens as keys with an expiration matching the token's exp claim—this way, expired tokens auto-clean themselves without manual maintenance.

Pros: Instant invalidation, minimal performance hit (Redis is faster than DB).
Cons: Adds a small overhead per request, requires Redis setup.

2. Split Access/Refresh Tokens #

Use a two-token system to separate short-lived access from long-lived refresh tokens:

• Access Token: Short expiry (15 mins), contains user roles/claims, used for all regular requests (no DB hit).
• Refresh Token: Long expiry (7+ days), stored securely in DB/Redis, only used to get a new Access Token when the old one expires.

When user info changes:

• Delete the user's Refresh Token from storage. The next time their Access Token expires, they'll be forced to re-authenticate, getting a new Access Token with updated roles.
• For immediate invalidation, you can also add the old Access Token to a blacklist.

Pros: Balances performance and security; refresh tokens let you avoid frequent logins while controlling access to updates.
Cons: Adds complexity to token management (handling refresh flows, secure storage of refresh tokens).

3. User Version Claim in JWT #

Add a user_version claim to your JWT, and track this version in your user database:

• When you issue a JWT, include the current user_version from the user's record (start at 1, increment on every role/password change).
• In your filter, after validating the JWT, fetch the user's current user_version from DB (or cached in Redis). If the JWT's version is lower than the DB version, reject the request—this means the user's info has changed since the token was issued.

Pros: No need to track individual tokens; detects changes instantly with a simple version check.
Cons: Adds a DB/Redis hit per request (but this is lighter than loading full UserDetails every time).

4. Cached User Info with Invalidation #

Cache user details in Redis, and invalidate the cache immediately when user info changes:

• Store user roles, password hashes, etc., in Redis with a short TTL (e.g., 5 mins).
• In your filter, load user details from Redis first; if the cache is empty, fetch from DB and populate the cache.
• When a user's role/password is updated, update the Redis cache immediately and optionally blacklist active tokens for instant invalidation.

Pros: Minimizes DB hits while keeping user info up-to-date.
Cons: Requires cache invalidation logic, adds dependency on Redis.

Your short-lived token approach is great for simplicity if you can tolerate a 15-minute delay in role changes. If you need instant updates, the token blacklist or user version claim methods are solid choices.

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