What is the AuthorizationManager interface in Spring Security, and what did it replace?
answer
- One SPI: AuthorizationManager<T>
- Replaced AccessDecisionManager + voters
- Supplier<Authentication> = lazy principal
- Returns AuthorizationDecision (granted boolean); null = abstain
- Used by AuthorizationFilter + method interceptors
basics
~10 sAuthorizationManager is Spring Security's interface that decides whether an authenticated user is allowed to access something. In Spring Security 6 it replaced the older AccessDecisionManager and voter system.
solid answer
~30 sAuthorizationManager<T> is the single decision-making SPI in Spring Security 6. Given the current Authentication (supplied lazily) and the object being secured (type T, e.g. an HTTP request or a method invocation), it returns an AuthorizationDecision saying granted or denied. It replaced the older, more complex AccessDecisionManager + AccessDecisionVoter chain from Spring Security 5.x, which used voters that returned ACCESS_GRANTED / DENIED / ABSTAIN integers. AuthorizationManager is simpler: one interface, generic over what you secure, with ready-made implementations like AuthorityAuthorizationManager (role/authority checks) and AuthenticatedAuthorizationManager (is-the-user-logged-in checks). It's used by AuthorizationFilter for web requests and by method-security interceptors for @PreAuthorize.
code
java · 10 lines// The SPI (simplified, classic form)
public interface AuthorizationManager<T> {
AuthorizationDecision check(Supplier<Authentication> authentication, T object);
}
// Wiring it into HTTP security
http.authorizeHttpRequests(auth -> auth
.requestMatchers("/public/**").permitAll()
.requestMatchers("/admin/**").hasRole("ADMIN") // AuthorityAuthorizationManager under the hood
.anyRequest().authenticated()); // AuthenticatedAuthorizationManagergo deeper
Know it's the yes/no access-decision interface and that it replaced the old voter system.
Explain the generic <T>, the Supplier<Authentication> laziness, and the granted/abstain semantics.
Contrast with AccessDecisionManager/voters and AffirmativeBased strategies; know AuthorizationFilter replaced FilterSecurityInterceptor.
Discuss deny-by-default migration risk, the check→authorize/AuthorizationResult evolution, and Observability integration.
## What it is `AuthorizationManager<T>` is the core authorization SPI (Service Provider Interface) in Spring Security 6.x. "Authorization" answers the question *"is this user allowed to do this?"* — as opposed to *authentication*, which answers *"who is this user?"*. The `<T>` type parameter is the thing being protected: for web requests it's `RequestAuthorizationContext` (wraps the `HttpServletRequest`); for method security it's `MethodInvocation` / `MethodInvocationResult`. ## The interface Historically the method was: ```java AuthorizationDecision check(Supplier<Authentication> authentication, T object); ``` In Spring Security 6.4+ that was superseded by `AuthorizationResult authorize(Supplier<Authentication>, T)` (with `AuthorizationDecision implements AuthorizationResult`), but the mental model is identical: input = the caller plus the guarded object, output = a decision. Two details matter: - **`Supplier<Authentication>`** — the `Authentication` is wrapped in a `Supplier` so it is resolved *lazily*. If a rule never needs the principal (e.g. `permitAll`), Spring never pays the cost of loading it. Calling `.get()` on an unauthenticated request can throw `AuthenticationCredentialsNotFoundException`. - **Return value** — `AuthorizationDecision` carries a boolean `isGranted()`. Returning `null` means **abstain** ("I have no opinion"), which lets a combining manager fall through to other rules. ## What it replaced Before 6.x, authorization went through `AccessDecisionManager`, which coordinated a list of `AccessDecisionVoter`s. Each voter returned an `int` constant (`ACCESS_GRANTED`, `ACCESS_DENIED`, `ACCESS_ABSTAIN`) and a strategy (`AffirmativeBased`, `ConsensusBased`, `UnanimousBased`) tallied the votes. This was flexible but verbose and hard to reason about. Spring Security 5.5 introduced `AuthorizationManager`; 5.8/6.0 made it the default and deprecated/removed the voter machinery. `FilterSecurityInterceptor` was replaced by `AuthorizationFilter`. ## Built-in implementations - **`AuthorityAuthorizationManager`** — checks GrantedAuthorities: `hasRole`, `hasAnyRole`, `hasAuthority`, `hasAnyAuthority`. - **`AuthenticatedAuthorizationManager`** — checks authentication *state*: `authenticated`, `fullyAuthenticated`, `rememberMe`, `anonymous`. - **`AuthorizationManagers`** — static combinators: `allOf`, `anyOf`, `not`. - **`WebExpressionAuthorizationManager`** — evaluates a SpEL expression. ## Where it's wired - Web: `authorizeHttpRequests { ... }` builds a `RequestMatcherDelegatingAuthorizationManager` that maps request matchers to `AuthorizationManager`s; `AuthorizationFilter` invokes it. - Method security: `@EnableMethodSecurity` registers `AuthorizationManagerBeforeMethodInterceptor` / `AuthorizationManagerAfterMethodInterceptor` for `@PreAuthorize` / `@PostAuthorize`. ## Gotcha Since 6.0, web authorization is **deny-by-default**: any request not matched by a rule is denied, and Spring throws if you leave requests unmapped. Always end with `anyRequest().authenticated()` or `.denyAll()`.
- Why is the Authentication passed as a Supplier rather than a plain Authentication?So it's resolved lazily — rules like permitAll never need the principal, so Spring avoids resolving it (and avoids throwing for unauthenticated requests) unless a rule actually calls .get().
- What does returning null from an AuthorizationManager mean?Abstain — no decision. A delegating/combining manager treats it as 'no opinion' and moves on; it is not the same as denying.
saying these in an interview costs you the question
- Saying AuthorizationManager handles authentication (login) — it only handles authorization.
- Claiming it still uses voters returning int constants — that's the removed AccessDecisionVoter model.
- Thinking null means 'deny' rather than 'abstain'.