skip to content

Authentication

4 roadmaps35 questions

Proving who the caller is: the manager and provider chain, user details and password storage, form and basic login, anonymous authentication, events and logout. Interviewers walk this path because a custom authentication mechanism is a common real-world task.

part ofSpring Frameworkoverview, primer and where to startread it →
on this pageshow

explore

questions

page 2 of 2

Why is server-side logout largely ineffective for stateless JWT authentication, and how do you design real logout for it?

level: principalimportance: should knowfreq 22%

basics

~20 s

A JWT is self-contained and validated by signature, not by server state, so invalidating a session does nothing — the token stays valid until it expires. Real logout needs short-lived tokens plus a server-side denylist or a rotated refresh token.

open as a page

From a security standpoint, what does DaoAuthenticationProvider do to resist username enumeration and timing attacks, and how do UserDetailsPasswordService and status flags fit in?

level: principalimportance: should knowfreq 30%

basics

~20 s

It hides whether a username exists by converting UsernameNotFoundException to BadCredentialsException (hideUserNotFoundExceptions=true), and it runs a dummy password hash for unknown users so response times don't reveal valid usernames. Account status flags block disabled/locked accounts, and UserDetailsPasswordService lets it transparently upgrade weak password hashes on login.

open as a page

In a stateless JWT REST API, is anonymous authentication useful, and when would you disable it? What are the trade-offs?

level: principalimportance: nice to knowfreq 22%

basics

~20 s

Anonymous still works statelessly (it is per-request, not session-based) and keeps Authentication non-null, which simplifies code. You might disable it if you want a null context to signal 'no user' explicitly, but usually leaving it on is fine and harmless.

open as a page

You have two AuthenticationProviders supporting the same token: a primary and a legacy fallback. A user's account is locked. Why might returning DisabledException/LockedException versus BadCredentialsException from the primary produce very different behavior, and how does that inform provider ordering and exception design?

level: principalimportance: nice to knowfreq 25%

basics

~20 s

If the primary throws an AccountStatusException (like LockedException), ProviderManager stops the chain immediately, so the legacy provider never runs and the user sees 'account locked'. If it throws BadCredentialsException, ProviderManager keeps going and the legacy provider may authenticate or reject, changing the outcome and the audit trail.

open as a page

You must migrate a production user base from {bcrypt} to {argon2} with zero downtime and no forced password resets. How do you design this with Spring Security's password APIs?

level: principalimportance: nice to knowfreq 35%

basics

~20 s

Use a DelegatingPasswordEncoder whose default encode id is argon2 but whose map still contains bcrypt for verification. Provide a UserDetailsPasswordService so that upgradeEncoding re-hashes each user to {argon2} on their next successful login. Old logins keep working throughout.

open as a page

showing 31–35 of 35