Consider defining a bean of type 'org.springframework.security.authentication.AuthenticationManager' in your configuration
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
This Spring Boot startup error means something is trying to inject AuthenticationManager, but Spring does not currently expose one as a bean in your application context. The fix depends on your Spring Security generation: modern Boot applications usually define the bean through AuthenticationConfiguration, while older applications used WebSecurityConfigurerAdapter.
Why the Error Appears
A common pattern is an authentication service that calls authenticate(...) directly.
That service is fine, but it assumes an AuthenticationManager bean exists. In Spring Security 5.7 and later, the framework no longer exposes that bean automatically just because you enabled web security.
Modern Fix for Spring Boot 3 and Spring Security 6
In current Spring Boot applications, define an AuthenticationManager bean by asking AuthenticationConfiguration for the manager Spring already knows how to build.
This works because Spring Security assembles the manager from your configured authentication providers, UserDetailsService, and password encoder.
Make Sure Supporting Beans Exist
Exposing the manager is not enough if the underlying authentication pieces are missing. A typical username-password setup also needs a UserDetailsService and PasswordEncoder.
If those beans are absent or inconsistent, the application may start but authentication will still fail at runtime.
Legacy Fix for Older Spring Boot Versions
If you are maintaining Spring Boot 2.x code that still uses WebSecurityConfigurerAdapter, the historical pattern was to override authenticationManagerBean().
That pattern is legacy now. Use it only when you are intentionally staying on the older stack.
When You Might Not Need the Bean
In some applications, nothing in your code needs to inject AuthenticationManager directly. If you rely entirely on Spring Security filters for form login, HTTP Basic, or bearer-token authentication, exposing the bean may be unnecessary. The error appears only when your own component asks for it through constructor injection or field injection.
That distinction is useful when cleaning up configuration. Sometimes the better fix is not to add another bean, but to remove a service dependency that duplicates what the filter chain already does. Keep direct AuthenticationManager usage for explicit programmatic login flows, custom authentication endpoints, or tests that truly need it.
Common Pitfalls
- Injecting
AuthenticationManagerand assuming Spring will expose it automatically in every version. That changed in newer Spring Security releases. - Defining the manager bean but forgetting
UserDetailsServiceorPasswordEncoder, which moves the failure from startup to runtime. - Copying
WebSecurityConfigurerAdapterexamples into a Spring Boot 3 project. Those examples target an older API generation. - Building a custom
AuthenticationProviderbut never registering it, leaving the manager with no provider that can authenticate your token. - Mixing multiple security configurations without understanding bean precedence. That can produce confusing startup behavior.
Summary
- The error means
AuthenticationManageris being injected but not exposed as a bean. - In modern Spring Security, declare it with
AuthenticationConfiguration.getAuthenticationManager(). - Ensure the supporting authentication beans are also configured.
- Use legacy
authenticationManagerBean()only for older Boot codebases. - Match the fix to your Spring Security version instead of mixing examples from different generations.

