Spring Boot 2.6.8+Keycloak拆分认证微服务可行性及校验流程咨询

该方案完全可行，是微服务架构中统一认证中心的典型落地模式，核心价值体现在：

• 解耦认证与业务：原资源服务器无需维护Keycloak依赖、令牌校验规则，可专注业务逻辑开发
• 统一认证策略：所有服务的令牌校验逻辑集中在认证微服务，避免多服务重复实现导致的规则不一致
• 降低耦合度：资源服务器不再直接依赖Keycloak实例，减少外部依赖变更对业务服务的影响
• 扩展性更强：后续新增资源服务时，无需重复集成Keycloak，直接对接统一认证微服务即可

针对Spring Boot 2.6.8的资源服务器，可通过以下几种方式对接认证微服务完成令牌校验：

1. 自定义Spring Security过滤器（推荐） #

基于Spring Security体系，在资源服务器中添加自定义过滤器拦截请求，调用认证微服务完成校验：

• 第一步：移除原资源服务器中Keycloak相关依赖与配置（如spring-boot-starter-oauth2-resource-server或Keycloak官方starter）
• 第二步：编写自定义过滤器AuthValidationFilter，继承OncePerRequestFilter，核心逻辑：
  • 从请求头Authorization: Bearer <token>中提取令牌
  • 通过RestTemplate或WebClient调用认证微服务的校验接口（如POST /auth/validate-token）
  • 校验通过：将用户身份信息（用户名、角色等）存入SecurityContextHolder，放行请求
  • 校验失败：直接返回401/403状态码，终止请求
• 第三步：在Spring Security配置类中注册该过滤器，确保其在安全过滤链的最前端执行

示例核心代码片段：

@Override
protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
    String authHeader = request.getHeader("Authorization");
    if (authHeader != null && authHeader.startsWith("Bearer ")) {
        String token = authHeader.substring(7);
        // 调用认证微服务校验令牌
        ResponseEntity<AuthValidationResponse> validationResp = restTemplate.postForEntity(
                "http://auth-service/auth/validate-token",
                new AuthValidationRequest(token),
                AuthValidationResponse.class
        );
        if (!validationResp.getStatusCode().is2xxSuccessful() || !validationResp.getBody().isValid()) {
            response.sendError(HttpServletResponse.SC_UNAUTHORIZED, "Invalid or expired token");
            return;
        }
        // 构建用户认证信息并存入上下文
        UserDetails userDetails = new User(
                validationResp.getBody().getUsername(),
                "",
                validationResp.getBody().getRoles().stream().map(SimpleGrantedAuthority::new).collect(Collectors.toList())
        );
        Authentication authentication = new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities());
        SecurityContextHolder.getContext().setAuthentication(authentication);
    }
    filterChain.doFilter(request, response);
}

2. API网关层统一校验（多资源服务场景优先） #

如果系统部署了API网关，可将令牌校验逻辑统一放在网关层：

• 网关拦截所有入口请求，调用认证微服务完成令牌校验
• 校验通过后，将用户身份信息（如X-User-Id、X-User-Roles）通过请求头传递给后端资源服务器
• 资源服务器只需校验请求头中是否存在合法的用户标识，无需再调用认证微服务
  这种方式能减少资源服务器与认证服务的重复交互，降低系统开销

3. 公钥缓存+状态校验（性能与解耦平衡） #

若使用JWT令牌，可采用“本地校验签名+远程校验状态”的混合模式：

• 认证微服务暴露GET /auth/public-key接口，返回JWT签名校验用的公钥
• 资源服务器通过定时任务拉取并缓存公钥，自行校验JWT的签名、过期时间等基础信息
• 对于令牌的业务状态（如是否被吊销），再调用认证微服务的接口确认
  该方式既能减少每次请求的远程调用开销，又能保证令牌状态的实时性

• 对接Keycloak完成令牌校验：可调用Keycloak的introspect接口，或使用Keycloak SDK验证令牌的合法性
• 对外提供统一的令牌校验接口：封装Keycloak的校验逻辑，向资源服务器返回简洁的校验结果（有效/无效、用户信息）
• 可选：维护令牌黑名单，支持手动吊销令牌的场景

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