关于Spring微服务中OAuth2资源服务器实现方式的疑问

Great question—this is a super common point of confusion when scaling OAuth2 across Spring-based microservices! Let’s break this down clearly, with practical options tailored to your setup.

First, the straightforward approach: you can absolutely have each microservice (suppliers, products, inventory) run its own Resource Server implementation. This is actually the default pattern recommended by Spring for distributed systems.

Here’s how it works:

• Each microservice adds the spring-security-oauth2-resource-server dependency to its pom.xml/build.gradle.
• Configure each service to validate tokens against your single Authentication Server (AS). For JWT tokens, this usually means pointing to the AS’s JWKS endpoint or using a shared signing key in your application.yml:

  spring:
    security:
      oauth2:
        resourceserver:
          jwt:
            issuer-uri: http://your-auth-server:8080
            jwk-set-uri: http://your-auth-server:8080/oauth2/jwks
  

• You can then use @PreAuthorize directly on your microservice controller methods (e.g., @PreAuthorize("hasAuthority('SCOPE_product:read')")) to enforce granular permissions.

Pros: #

• Each service is independent—no single point of failure for permission checks.
• You can tune permissions per service without affecting others.
• No extra infrastructure needed beyond your existing AS and microservices.

Cons: #

• Configuration duplication: You’ll need to replicate the Resource Server setup across every microservice. Updates to token validation logic require changes to all services.

If you want to avoid repeating configuration across services, you can implement a centralized permission layer—typically using a Spring Cloud Gateway that acts as your single Resource Server. All microservice requests pass through this gateway, which handles token validation and permission checks before routing traffic to the appropriate service.

Here’s how to set this up:

1. Create a Gateway Service:
   • Add dependencies: spring-cloud-starter-gateway and spring-security-oauth2-resource-server.
2. Configure Gateway Routes:
   Map incoming requests to your microservices in application.yml:

   spring:
     cloud:
       gateway:
         routes:
           - id: suppliers-service
             uri: lb://suppliers-service
             predicates:
               - Path=/suppliers/**
           - id: products-service
             uri: lb://products-service
             predicates:
               - Path=/products/**
   

3. Implement Gateway-Level Security:
   Use a SecurityFilterChain to enforce token validation and permissions globally:

   @Bean
   public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
       http
           .authorizeHttpRequests(auth -> auth
               // Enforce permissions per route
               .requestMatchers("/suppliers/**").hasAuthority("SCOPE_supplier:read")
               .requestMatchers("/products/admin/**").hasAuthority("SCOPE_product:admin")
               .anyRequest().authenticated()
           )
           .oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()));
       return http.build();
   }
   

4. Simplify Microservices:
   Your individual microservices no longer need full Resource Server setup. You can optionally add lightweight token validation (e.g., verifying the token’s signature and issuer) as a safeguard against direct requests bypassing the gateway, but permission checks are handled entirely by the gateway.

Pros: #

• Single source of truth for permission rules—update once, apply everywhere.
• Reduces boilerplate code in microservices.
• Acts as a unified entry point for all external requests.

Cons: #

• The gateway becomes a critical component; if it fails, all microservices are inaccessible.
• Granular method-level permissions (e.g., specific endpoints in a microservice) require more detailed routing and rule configuration in the gateway.

• Token Type Matters: If using JWT, the gateway or microservices can validate tokens locally (without calling the AS) if they have access to the public key/JWKS endpoint. For opaque tokens, you’ll need to configure the Resource Server to call the AS’s introspection endpoint to validate tokens.
• Defense in Depth: Even with a centralized gateway, adding basic token validation to microservices is a good idea to prevent unauthorized direct access (e.g., if someone finds a way to bypass the gateway).
• Permission Storage: If your permissions are dynamic (not embedded in JWTs), you’ll need a way to fetch them (e.g., a shared permission database or calling the AS’s user info endpoint) during validation—either in each microservice or the gateway.

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