Why Spring Authorization Server Merged into Spring Security 7.0 and How to Migrate

What Is Spring Authorization Server?

Before discussing the migration, it is essential to understand the role of an OAuth2 authorization server, which issues and validates tokens so that multiple micro‑services can share a single authentication point.

Core Responsibilities of an Authorization Server

Issue Tokens : Generate Access Token and Refresh Token after successful login.

Validate Tokens : Allow downstream services to verify token authenticity and expiration.

Manage Clients : Record which applications are permitted to request tokens.

Spring Authorization Server (SAS) implements these functions following OAuth 2.1 and OpenID Connect 1.0 standards.

SAS Core Capabilities

Supported Grant Types : Authorization Code, Client Credentials, Device Authorization, PKCE extension.

OIDC Features : UserInfo endpoint, discovery document (/.well-known/openid-configuration), ID Token issuance.

Three Eras of OAuth in the Spring Ecosystem

Legacy Era – spring-security-oauth : An outdated project with a monolithic architecture, reliance on WebSecurityConfigurerAdapter, and no support for OAuth 2.1 features such as mandatory PKCE. It has been officially EOL for years.

Incubation Era – Independent spring-authorization-server : Created to fill the gap, offering rapid iteration, a clean design based on OAuth 2.1, and a modular architecture separating authorization, token, and introspection endpoints.

Unified Era – Merged into Spring Security 7.0 : The independent repository is discontinued; SAS code is now part of the main Spring Security source tree, sharing the same version number and BOM, eliminating version‑sync and dependency‑management issues.

Technical Stack Alignment

Spring Security 7.0 requires Java 17+ and Jakarta EE 11 (package rename from javax.* to jakarta.*). Consequently, SAS now inherits these baseline requirements, preventing mismatched runtime environments.

Migration in Practice: From SpringBoot 3 to SpringBoot 4

Dependency Changes

When using the starter, the artifactId changes as follows:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security-oauth2-authorization-server</artifactId>
</dependency>

If you depend directly on the library, the coordinates become:

<!-- SpringBoot 3 -->
<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-oauth2-authorization-server</artifactId>
    <version>1.5.5</version>
</dependency>

<!-- SpringBoot 4 – version follows Spring Security BOM, no explicit version needed -->
<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-oauth2-authorization-server</artifactId>
</dependency>

Configuration Changes: Lambda DSL

Spring Security 7.0 removes the old .and() chaining style and requires a functional‑style Lambda DSL. The previous configuration looked like this:

@Bean
@Order(1)
public SecurityFilterChain pigAuthServerFilterChain(HttpSecurity http) throws Exception {
    OAuth2AuthorizationServerConfiguration.applyDefaultSecurity(http);
    http.exceptionHandling()
        .authenticationEntryPoint(new LoginUrlAuthenticationEntryPoint("/login"))
        .and()
        .oauth2ResourceServer().jwt();
    return http.build();
}

The new approach explicitly creates a configurator and uses lambdas for each section:

@Bean
@Order(1)
public SecurityFilterChain pigAuthServerFilterChain(HttpSecurity http) throws Exception {
    OAuth2AuthorizationServerConfigurer authorizationServerConfigurer = new OAuth2AuthorizationServerConfigurer();
    RequestMatcher endpointsMatcher = authorizationServerConfigurer.getEndpointsMatcher();

    http.securityMatcher(endpointsMatcher)
        .authorizeHttpRequests(auth -> auth.anyRequest().authenticated())
        .csrf(csrf -> csrf.ignoringRequestMatchers(endpointsMatcher))
        .exceptionHandling(ex -> ex.authenticationEntryPoint(new LoginUrlAuthenticationEntryPoint("/login")))
        .oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()))
        .with(authorizationServerConfigurer, authServer -> authServer.oidc(Customizer.withDefaults()));

    return http.build();
}

Key differences:

No longer call applyDefaultSecurity; all defaults must be configured explicitly.

All .and() calls are replaced by lambda expressions, making the scope of each configuration clearer.

The securityMatcher is set to limit the filter chain to authorization‑server endpoints, avoiding conflicts with other chains.

Final Thoughts

The migration effort is modest: update the Maven coordinates, replace the deprecated .and() chains with the new Lambda DSL, and ensure the project runs on Java 17+ with Jakarta EE 11 packages. Most of the work is already familiar to developers who have upgraded to Spring Security 6.x, so the transition to SpringBoot 4 and Spring Security 7.0 should be straightforward.