Spring Authorization Server, OAuth2 client and resource server: three trust roles

Separate the trust roles

A parcel dashboard signs in an operator through an authorization server. The dashboard is an OAuth2 client; the parcel API is a resource server. The issuer authenticates the operator, records the client and grant, and signs or otherwise issues a token. The API verifies issuer, signature, expiry and intended audience before it evaluates scopes. Resource-server validation does not issue tokens, and client token acquisition does not make the client an issuer.

Keep issuer identity stable

The API must trust the configured issuer rather than any token with a parseable JWT shape. Keep one externally stable issuer identifier across replicas. Rotate signing keys without replacing every active key at once, and expose verification keys through the issuer's configured metadata. A fresh key generated only in process memory on every restart can invalidate tokens that were already issued. Audience checks stop a valid token for another API from being accepted here.

Test the wrong recipient

Issue a token for parcel-read, then send it to the billing API. It must fail if that API expects a different audience even when the signature and issuer are valid. Also test an expired token and a token signed by an untrusted issuer. The security-filter configuration below is a starting sketch; it does not supply registered clients, durable authorization state or stable signing keys.

Implementation sketch

@Bean
SecurityFilterChain issuerChain(HttpSecurity http) throws Exception {
    http.oauth2AuthorizationServer(server -> {
        http.securityMatcher(server.getEndpointsMatcher());
        server.oidc(Customizer.withDefaults());
    }).authorizeHttpRequests(auth -> auth.anyRequest().authenticated());
    return http.build();
}

Cost and verification

Token validation can be local when verification keys are cached, but key lookup and rotation still need controlled refresh. Issuing tokens adds persistent client and authorization records when revocation or refresh is required.

Common Mistakes

• Do not treat a resource server as an authorization server because both use Spring Security.
• Do not accept a token merely because it has a valid signature; check issuer and audience.
• Do not generate a new production signing key at every startup and expect old tokens to remain valid.

Read next

Spring Security JWT resource server: validate trust before checking scope, Spring OAuth2 client credentials: acquire and reuse a service token, Spring resource server JWT: validate both issuer and intended audience, Spring Authorization Server JDBC state: clients, grants and consent across restarts.