Running an Authorization Server

Most Spring apps are resource servers or clients - they validate tokens or obtain them. Running an authorization server is the other side: the party that authenticates users and mints tokens in the first place. Spring Authorization Server is the official project for this. Understanding what it is (and when you actually need it) matters as much as the config.

Issuing vs. validating

Keep three responsibilities distinct - they're three different Spring modules:

• Resource Server (spring-boot-starter-oauth2-resource-server) - validates incoming tokens and protects endpoints. This is what BookVault's API did with its HS256 shortcut.
• Client (spring-boot-starter-oauth2-client) - obtains tokens by driving a login flow ("Sign in with Google").
• Authorization Server (spring-security-oauth2-authorization-server) - issues tokens: authenticates the user, runs the grants, exposes the OAuth2/OIDC endpoints.

You only run an authorization server when you want to be the identity provider - your own login, your own tokens, multiple apps trusting one issuer. If you just want users to log in with Google or Okta, you're a client, not an authorization server.

A minimal server

Spring Authorization Server is a set of Spring Security filters you enable and configure. The core is a security filter chain that applies the OAuth2/OIDC endpoint defaults:

@Configuration
class AuthServerConfig {

    @Bean
    @Order(1)
    SecurityFilterChain authServer(HttpSecurity http) throws Exception {
        OAuth2AuthorizationServerConfigurer.authorizationServer()
            .oidc(Customizer.withDefaults());              // enable OpenID Connect
        return http
            .securityMatcher("/oauth2/**", "/.well-known/**", "/userinfo")
            .with(OAuth2AuthorizationServerConfigurer.authorizationServer(), c -> c.oidc(withDefaults()))
            .build();
    }

    @Bean
    @Order(2)
    SecurityFilterChain login(HttpSecurity http) throws Exception {
        return http.formLogin(withDefaults()).build();     // how users authenticate
    }
}

Turning it on exposes the standard endpoints automatically: /oauth2/authorize, /oauth2/token, /oauth2/jwks (the public keys), and the discovery document at /.well-known/openid-configuration that clients read to auto-configure.

Registering clients

An authorization server won't issue tokens to anyone - each app must be a registered client with an ID, (for confidential clients) a secret, its allowed redirect URIs, grant types, and scopes:

@Bean
RegisteredClientRepository clients(PasswordEncoder encoder) {
    RegisteredClient bookvaultSpa = RegisteredClient.withId(UUID.randomUUID().toString())
        .clientId("bookvault-web")
        .clientAuthenticationMethod(ClientAuthenticationMethod.NONE)     // public client (SPA)
        .authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE)
        .redirectUri("https://app.bookvault.dev/callback")               // exact match required
        .scope(OidcScopes.OPENID).scope("catalog:read")
        .clientSettings(ClientSettings.builder().requireProofKey(true).build())  // PKCE
        .build();
    return new InMemoryRegisteredClientRepository(bookvaultSpa);
}

Every field is a security boundary: the exact redirect URI stops token theft via open redirects, the grant types limit what the client may do, and the scopes cap what its tokens can access.