我完全懂你的困惑——很多Spring Security JWT示例里的认证逻辑都依赖UserDetailsService从数据库拉取用户信息，这看起来和传统的基于数据库的令牌认证没太大区别，好像没完全发挥JWT“自包含”的特性，确实容易让人疑惑。

先说说为什么那些示例要这么做 #

其实这主要是两个原因：

• 适配Spring Security生态：Spring Security的核心认证流程围绕Authentication对象展开，而UserDetailsService是框架提供的标准入口，用来获取用户的权限、账号状态（比如是否禁用、锁定）等元数据。很多示例为了兼容框架的现有授权逻辑（比如@PreAuthorize方法级注解），会通过JWT拿到用户名后，再去数据库拉取完整的用户信息，这样能无缝对接框架的各种安全特性。
• 安全与灵活性考量：如果把权限等敏感信息直接存在JWT里，一旦签发就无法实时修改或收回（除非设置很短的过期时间）。而通过UserDetailsService从数据库实时获取权限，就能动态调整用户的权限，比如用户被降级后，下次请求就能立即生效，安全性更高。

再分析你的两个思路，给点实际建议 #

思路1：自定义Authentication与AuthenticationProvider

这个方案适合想完全自定义认证逻辑的场景，优势很明显：

• 彻底摆脱对UserDetailsService和数据库的依赖，直接从JWT Payload里解析出所有需要的信息（用户名、权限、角色等），封装到自己的Authentication实现类中。
• 自定义AuthenticationProvider来处理验证逻辑，只需要校验JWT的签名有效性，不需要查询数据库，完全发挥JWT自包含的特性。

给你一段简化的示例代码参考：

// 自定义Authentication实现类
public class JwtAuthenticationToken extends AbstractAuthenticationToken {
    private final String username;

    public JwtAuthenticationToken(String username, Collection<? extends GrantedAuthority> authorities) {
        super(authorities);
        this.username = username;
        setAuthenticated(true); // 签名验证通过后标记为已认证
    }

    @Override
    public Object getCredentials() {
        return null; // JWT令牌已经在过滤器中处理，这里不需要返回凭证
    }

    @Override
    public Object getPrincipal() {
        return username;
    }
}

// 自定义AuthenticationProvider
@Component
public class JwtAuthenticationProvider implements AuthenticationProvider {
    private final JwtUtil jwtUtil;

    public JwtAuthenticationProvider(JwtUtil jwtUtil) {
        this.jwtUtil = jwtUtil;
    }

    @Override
    public Authentication authenticate(Authentication authentication) throws AuthenticationException {
        String token = (String) authentication.getCredentials();
        // 验证JWT签名和过期时间
        if (!jwtUtil.isTokenValid(token)) {
            throw new BadCredentialsException("无效的JWT令牌");
        }
        // 从JWT解析用户信息和权限
        String username = jwtUtil.extractUsername(token);
        List<GrantedAuthority> authorities = jwtUtil.extractAuthoritiesFromToken(token);
        // 返回自定义认证对象
        return new JwtAuthenticationToken(username, authorities);
    }

    @Override
    public boolean supports(Class<?> authentication) {
        return JwtAuthenticationToken.class.isAssignableFrom(authentication);
    }
}

思路2：用JwtUtil解码后创建UsernamePasswordAuthenticationToken

这个方案更轻量，适合不想过多自定义组件的场景：

• 直接在JWT过滤器中解析令牌，拿到用户名和权限后，创建Spring Security标准的UsernamePasswordAuthenticationToken，然后设置到SecurityContextHolder中即可。
• 这种方式不需要自定义AuthenticationProvider，代码更简洁，但要注意：JWT中的权限信息必须是可信的（因为跳过了数据库校验），如果需要动态调整权限，这个方案就不太合适了。

示例代码片段：

@Component
public class JwtAuthenticationFilter extends OncePerRequestFilter {
    private final JwtUtil jwtUtil;

    public JwtAuthenticationFilter(JwtUtil jwtUtil) {
        this.jwtUtil = jwtUtil;
    }

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        String token = extractTokenFromHeader(request);
        if (token != null && jwtUtil.isTokenValid(token)) {
            String username = jwtUtil.extractUsername(token);
            // 从JWT中解析权限，这里假设JWT里存了权限列表
            List<GrantedAuthority> authorities = jwtUtil.extractAuthorities(token);
            // 创建标准认证对象，凭证设为null（因为JWT已经验证过）
            Authentication auth = new UsernamePasswordAuthenticationToken(username, null, authorities);
            // 将认证信息存入SecurityContext
            SecurityContextHolder.getContext().setAuthentication(auth);
        }
        filterChain.doFilter(request, response);
    }

    private String extractTokenFromHeader(HttpServletRequest request) {
        String authHeader = request.getHeader("Authorization");
        if (StringUtils.hasText(authHeader) && authHeader.startsWith("Bearer ")) {
            return authHeader.substring(7);
        }
        return null;
    }
}

最后总结一下 #

两种方案各有适用场景：

• 如果你的系统需要动态权限控制、账号状态管理（比如锁定、禁用），建议保留UserDetailsService的方式，虽然看起来像传统令牌，但能兼顾Spring Security的安全性和扩展性。
• 如果追求极致性能，且权限信息不需要实时调整，那么你的两个思路都可行——思路1更灵活，适合复杂的自定义场景；思路2更简洁，适合快速实现JWT自包含认证。

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