Spring Security: JWT، OAuth2 و مجوزدهیSpring Security: JWT, OAuth2 & Authorization

Most people picture Spring Security as a magical black box that "somehow" keeps people out. The truth is far more calming: it's a line of guards standing one behind another, each doing one small job. Once you hold that picture, everything else — JWT, OAuth2, CSRF — becomes just details of that line. Let's build it from scratch.

Part 0 — words you must know

Before we start, let's unpack a few terms with a quick analogy so we don't trip on them later:

• Servlet Filter: in Java web apps, every HTTP request passes through a chain of "filters" before it reaches your code. A filter is like a doorman who can inspect, modify, reject, or wave the request through. Spring Security is nothing but a few clever filters.
• Principal: "the entity currently speaking" — usually the logged-in user. The name comes from logic, but it just means "the current identity."
• Authority / GrantedAuthority: a permission label stuck to the user, like ROLE_ADMIN or SCOPE_read. The set of these labels decides what the user can do.
• Token: a portable piece of data that says "my holder is authenticated." Instead of resending a password every time, you flash this card.
• Stateless: the server keeps no memory of you between two requests. Each request must be complete and self-proving on its own.

With those in hand, let's get to the heart of it.

Mental model: it's a filter chain, not magic

At its core, Spring Security is a single servlet Filter (DelegatingFilterProxy → FilterChainProxy) that Spring Boot registers early in the container's filter list. Every HTTP request passes through this proxy, which selects one SecurityFilterChain (the first whose RequestMatcher matches) and runs its ordered list of internal filters. Nothing about Spring Security is aspect-oriented at the web layer — it is plain servlet filters executing in a fixed order.

That order matters and interviewers probe it. A simplified, representative slice of the default chain:

DisableEncodeUrlFilter
SecurityContextHolderFilter        // loads/saves SecurityContext (was SecurityContextPersistenceFilter)
CsrfFilter                         // validates CSRF token for state-changing methods
LogoutFilter
UsernamePasswordAuthenticationFilter  // processes form login POST /login
...
BearerTokenAuthenticationFilter    // OAuth2 resource server: extracts Bearer token
...
ExceptionTranslationFilter         // catches AuthenticationException / AccessDeniedException
AuthorizationFilter                // the LAST filter: enforces authorizeHttpRequests rules

Let's read that line by line. The names look scary, but each does something simple: SecurityContextHolderFilter runs first to pull out a stored identity if a session exists. CsrfFilter checks the anti-forgery token. UsernamePasswordAuthenticationFilter handles the login form. BearerTokenAuthenticationFilter pulls the JWT out of the header. And at the very end, AuthorizationFilter makes the final access decision.

Here's the key insight that makes everything click: authentication filters run before AuthorizationFilter. An authentication filter's job is only to populate the SecurityContextHolder with an Authentication; it does not decide access. The final AuthorizationFilter reads that Authentication and applies your rules.

If a request reaches AuthorizationFilter unauthenticated and hits a protected rule, an AccessDeniedException is thrown, caught by ExceptionTranslationFilter, which then either starts authentication (redirect to login / send 401) or returns 403. Keep the 401-vs-403 distinction in mind: 401 means "I don't know who you are" (unauthenticated) and 403 means "I know who you are, but you're not allowed" (authenticated but forbidden).

Authentication vs authorization

• Authentication — who are you? Produces an Authentication object (principal + credentials + authorities) stored in SecurityContextHolder (a ThreadLocal by default).
• Authorization — are you allowed to do this? Compares the authenticated principal's GrantedAuthority set against a rule (URL rule via authorizeHttpRequests, or method rule via @PreAuthorize).

Now a subtle but crucial distinction that swallows thousands of debugging hours a year: authorities vs roles. A role is just an authority with the conventional ROLE_ prefix. That's it — a role is nothing special, just an authority we've agreed to prefix with ROLE_. hasRole("ADMIN") checks under the hood for authority ROLE_ADMIN; hasAuthority("ROLE_ADMIN") is equivalent. hasAuthority("ADMIN") is not.

Spring Security 6 config style — component-based, no adapter

If you've seen old tutorials, you've probably seen a class that extended WebSecurityConfigurerAdapter and overrode methods. That era is over.

The new philosophy is simple: instead of "I inherit from a parent class and tweak its behavior," you say "I build a SecurityFilterChain and hand it to Spring." That's the difference between tuning a pre-built machine and assembling your own parts — clearer and more composable.

@Configuration
@EnableWebSecurity
@EnableMethodSecurity            // replaces @EnableGlobalMethodSecurity; prePostEnabled=true by default
public class SecurityConfig {

    @Bean
    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            // requestMatchers replaces antMatchers/mvcMatchers (removed in 6)
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/public/**", "/actuator/health").permitAll()
                .requestMatchers(HttpMethod.POST, "/api/orders").hasRole("USER")
                .requestMatchers("/admin/**").hasRole("ADMIN")
                .anyRequest().authenticated())   // deny-by-default: keep this last
            .httpBasic(Customizer.withDefaults())
            .formLogin(Customizer.withDefaults());
        return http.build();
    }

    @Bean
    PasswordEncoder passwordEncoder() {
        // DelegatingPasswordEncoder: stores {bcrypt}$2a$... so you can migrate algorithms later
        return PasswordEncoderFactories.createDelegatingPasswordEncoder();
    }
}

Let's read it: authorizeHttpRequests lays out access rules — from specific to general. permitAll() means "everyone in," hasRole("USER") means "USER only," and the final anyRequest().authenticated() means "anything else must at least be logged in." That last one is the deny-by-default policy and must always be the final rule.

Three removed/renamed items to know cold (these are interview fodder):

• authorizeRequests() → authorizeHttpRequests() (the new one runs after the servlet dispatch, integrates with AuthorizationManager).
• antMatchers() / mvcMatchers() / regexMatchers() → requestMatchers().
• @EnableGlobalMethodSecurity(prePostEnabled=true) → @EnableMethodSecurity (pre/post enabled by default; uses AuthorizationManager).

Because you now just declare beans, you can define multiple SecurityFilterChain beans and order them with @Order and a securityMatcher — the classic pattern for splitting a stateless /api/** chain from a stateful UI chain, like having two separate entrance doors for customers and staff:

@Bean @Order(1)
SecurityFilterChain apiChain(HttpSecurity http) throws Exception {
    http.securityMatcher("/api/**")               // this chain only handles /api/**
        .csrf(csrf -> csrf.disable())             // stateless API, see CSRF section
        .sessionManagement(s -> s.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
        .authorizeHttpRequests(a -> a.anyRequest().authenticated())
        .oauth2ResourceServer(o -> o.jwt(Customizer.withDefaults()));
    return http.build();
}

@Order(1) means this chain is checked first; securityMatcher("/api/**") means it's only active for /api paths. The first matching chain wins, and only that chain's filters run.

UserDetailsService and password encoding

Now a question: when a user sends a username and password, how does Spring know the password is correct?

For username/password auth, the DaoAuthenticationProvider calls your UserDetailsService#loadUserByUsername, then delegates password comparison to the PasswordEncoder.

@Service
public class JpaUserDetailsService implements UserDetailsService {
    private final UserRepository repo;
    JpaUserDetailsService(UserRepository repo) { this.repo = repo; }

    @Override
    public UserDetails loadUserByUsername(String username) {
        var u = repo.findByUsername(username)
            .orElseThrow(() -> new UsernameNotFoundException(username));
        return User.withUsername(u.getUsername())
            .password(u.getPasswordHash())        // already a {bcrypt} hash
            .authorities(u.getRoles().stream()    // e.g. "ROLE_USER"
                .map(SimpleGrantedAuthority::new).toList())
            .build();
    }
}

Notice we never store the raw password in the database — we always store a hash. A hash is a one-way function that turns the password into a scrambled string that (practically) cannot be reversed.

BCrypt is the default recommendation: it's a deliberately slow, salted, adaptive hash. "Salted" means a random value is mixed into the password so two users with the same password get different hashes (this defeats precomputed tables). The salt is embedded in the output ($2a$10$<22-char-salt><31-char-hash>), so you never store a separate salt column. The 10 is the cost (work factor) — each +1 doubles the work ("adaptive" means exactly this: as hardware gets faster, you raise the number). Encode on registration with passwordEncoder.encode(raw); never compare hashes yourself — use matches(raw, stored), which is constant-time-ish and parses the parameters from the stored value.

Why DelegatingPasswordEncoder? Because its output carries a prefix like {bcrypt}. That prefix tells Spring which algorithm produced each hash, so tomorrow you can switch algorithms without breaking old users — old hashes are still checked with their old prefix.

Stateless JWT flow

So far we assumed the server keeps a session. But if you have 10 servers and want a user to work no matter which one they hit, sessions become a headache. This is where JWT enters.

A JWT is a self-contained, signed token: header.payload.signature, base64url-encoded. It has three dot-separated parts: the header (which algorithm signed it), the payload (the claims — like the user's name and roles), and the signature (the tamper-proof stamp).

The stateless flow works like this:

1. Client authenticates once (POST /login with credentials).
2. Server verifies, then issues a short-lived access token (JWT, e.g. 5–15 min) signed with a secret (HMAC/HS256) or private key (RSA/EC, RS256/ES256).
3. Client sends Authorization: Bearer <token> on every request.
4. Server validates the signature and claims on each request — no session, no DB lookup. That statelessness is the whole point (horizontal scaling, no sticky sessions).

An important engineering note: prefer treating your own service as an OAuth2 Resource Server rather than hand-rolling a filter, even for self-issued tokens — you get battle-tested validation for free:

http.oauth2ResourceServer(o -> o.jwt(jwt -> jwt
        .jwtAuthenticationConverter(authConverter())));

# RS256 with an external/OIDC provider — discovers keys via /.well-known
spring.security.oauth2.resourceserver.jwt.issuer-uri=https://issuer.example.com
# or, for self-issued HS256, provide a decoder bean instead:

@Bean
JwtDecoder jwtDecoder(@Value("${jwt.secret}") String secret) {
    var key = new SecretKeySpec(secret.getBytes(), "HmacSHA256");
    var decoder = NimbusJwtDecoder.withSecretKey(key).build();
    // Layer validators: default (exp/nbf) + issuer + audience
    decoder.setJwtValidator(new DelegatingOAuth2TokenValidator<>(
        JwtValidators.createDefaultWithIssuer("my-auth"),
        new JwtClaimValidator<List<String>>("aud", aud -> aud != null && aud.contains("my-api"))));
    return decoder;
}

Here we have three layers of validation: the default (exp expiry and nbf, "not before" — not valid before this time), then an issuer check (who minted it), then an audience check (aud — which service this token is for). Each layer, a sturdier door.

Now you map the token's claims to Spring authorities. By default Spring maps the scope/scp claim to SCOPE_* authorities. To map a custom roles claim to ROLE_*:

JwtAuthenticationConverter authConverter() {
    var granted = new JwtGrantedAuthoritiesConverter();
    granted.setAuthoritiesClaimName("roles");
    granted.setAuthorityPrefix("ROLE_");
    var conv = new JwtAuthenticationConverter();
    conv.setJwtGrantedAuthoritiesConverter(granted);
    return conv;
}

Refresh tokens — the part people get wrong

Here's an apparent contradiction: we said the access token is short-lived (5–15 min). But you don't want to ask the user for a password every 15 minutes. The solution: the refresh token.

Access tokens must be short-lived because you can't revoke a stateless JWT before it expires. To avoid re-prompting for credentials, issue a long-lived refresh token alongside. Critical properties:

• The refresh token is opaque and stored server-side (DB/Redis), so it can be revoked. It is not a JWT you blindly trust.
• On refresh, validate it against the store, then rotate it (issue a new refresh token, invalidate the old). Rotation lets you detect theft: if an already-used refresh token is presented again, treat the family as compromised and revoke all.
• Access token: minutes. Refresh token: days/weeks.

Where to store tokens (browser)

This is a security-design question, not a Spring one:

Here XSS means an attack that injects malicious JS into your page; if the token lives somewhere JS can read it (like localStorage), that malicious code can steal it.

JWT pitfalls

• You cannot revoke early. Logout is client-side only unless you add a server-side denylist (which reintroduces state). Keep access tokens short instead.
• alg: none — historically, some libraries accepted unsigned tokens (i.e. an attacker declares "my algorithm is none" and sails through unstamped!). Spring/Nimbus rejects this, but never allow the token to dictate the algorithm.
• Algorithm confusion — an attacker resigns an RS256 token as HS256 using the public key as the HMAC secret. Pin the expected algorithm; don't let the header choose.
• Clock skew — validate exp/nbf with a small leeway (NimbusJwtDecoder allows configuring the clock skew). Why: server clocks aren't perfectly synced, and without leeway a just-issued token can be rejected as "not yet valid."
• Bloat — putting roles/permissions in the token means they're stale until expiry (change a user's access and the old token still carries the old access), and large tokens hit header-size limits.

OAuth2 / OIDC roles

The name OAuth2 scares many, but the core is a simple idea: "how do I let app B touch app A's data on my behalf, without handing my password to B?"

OAuth2 is a delegated authorization framework; OIDC layers authentication (identity) on top of it via the id_token. Spring Security implements three distinct roles — interviewers love checking you don't conflate them:

Three words that constantly get muddled, scope vs claim vs authority:

• A claim is any key/value in the token (sub, iss, email, roles) — any "assertion" the token makes about its holder.
• A scope is a specific claim (scope) expressing what the token is permitted to do — coarse-grained, consent-driven. Spring maps it to SCOPE_read etc.
• Authorities are Spring's internal representation; you decide how claims/scopes become authorities.

.requestMatchers("/api/reports/**").hasAuthority("SCOPE_reports:read")

And an important note about how you obtain a token: the Authorization Code flow with PKCE is the correct flow for both SPAs and server-side web apps today (the implicit flow is deprecated). PKCE (code_verifier/code_challenge) binds the authorization code to the client that started the flow — as if the code you receive only unlocks with your own "secret padlock" — preventing code interception.

Method security — @PreAuthorize and friends

URL rules are coarse: "anyone going to /admin must be ADMIN." But some rules are finer: "a user may see only their own documents." We express such rules close to the code.

@EnableMethodSecurity activates SpEL-based (Spring Expression Language) annotations:

@Service
public class DocumentService {

    @PreAuthorize("hasRole('ADMIN')")
    public void purge() { /* ... */ }

    // Access the method argument and the principal via SpEL
    @PreAuthorize("#ownerId == authentication.name or hasRole('ADMIN')")
    public List<Doc> listFor(String ownerId) { /* ... */ }

    // @PostAuthorize filters the RETURNED object after execution
    @PostAuthorize("returnObject.owner == authentication.name")
    public Doc get(Long id) { /* ... */ }

    // @PreFilter / @PostFilter filter collection elements in/out
    @PostFilter("filterObject.visibility == 'PUBLIC' or filterObject.owner == authentication.name")
    public List<Doc> search(String q) { /* ... */ }
}

See how powerful this is: #ownerId refers to the method argument and authentication.name to the logged-in user — so you can say "only if you own the document, or you're an admin." returnObject refers to the return value and filterObject to each element of the list.

Two more gotchas that separate seniors from juniors:

• @PostAuthorize runs after the method executes — any side effects already happened (rows deleted, emails sent). Never use it to guard a mutating method; only to filter the output of read-only methods.
• Prefer @EnableMethodSecurity over the deprecated @Secured/JSR-250 unless you need those specifically; @PreAuthorize with SpEL is strictly more expressive.

CSRF — when it actually matters

CSRF is one of those topics everyone has heard of but few know exactly when it matters.

CSRF (Cross-Site Request Forgery) exploits ambient credentials the browser sends automatically — chiefly cookies. If your app authenticates via a session cookie or any auto-sent cookie, a malicious site can trigger a state-changing request from the victim's browser, and the cookie rides along.

The nuance that catches many: if your "stateless" API stores the JWT in a cookie, CSRF is back on the table — now the browser auto-sends it. Use SameSite cookies and CSRF tokens.

Spring 6 uses a CsrfTokenRequestAttributeHandler and (for SPAs) the CookieCsrfTokenRepository.withHttpOnlyFalse() pattern where JS reads the token from a cookie and echoes it in a header.

CORS — a browser policy, not a security control

This is perhaps misunderstood more than any other topic. Let me be blunt up front: CORS does not make you secure.

CORS (Cross-Origin Resource Sharing) is enforced by the browser, relaxing the Same-Origin Policy for reads. It is not authentication or authorization — it only governs whether browser JS may read a cross-origin response. Configure it in Spring so preflight (OPTIONS) requests succeed (preflight is the trial OPTIONS request the browser sends before the real one to ask "am I allowed?"):

@Bean
SecurityFilterChain chain(HttpSecurity http) throws Exception {
    http.cors(Customizer.withDefaults());   // picks up the CorsConfigurationSource bean below
    return http.build();
}

@Bean
CorsConfigurationSource corsSource() {
    var cfg = new CorsConfiguration();
    cfg.setAllowedOrigins(List.of("https://app.example.com"));  // never "*" with credentials
    cfg.setAllowedMethods(List.of("GET", "POST", "PUT", "DELETE"));
    cfg.setAllowedHeaders(List.of("Authorization", "Content-Type"));
    cfg.setAllowCredentials(true);
    var src = new UrlBasedCorsConfigurationSource();
    src.registerCorsConfiguration("/**", cfg);
    return src;
}

Note ordering: enable CORS in Spring Security (http.cors(...)) so the CorsFilter runs before authentication and doesn't reject preflight OPTIONS requests (which carry no credentials). If you get this ordering wrong, the preflight hits the auth filter, gets a 401, and the browser never sends the real request at all.

Common pitfalls & best practices

• Deny by default. A forgotten endpoint should fail closed.
• permitAll() doesn't strip authentication — it allows the request; the SecurityContext may still be populated. And permitAll() on a path won't help if a later, more specific matcher isn't reached — rules are evaluated top-to-bottom, first match wins. Order specific rules before general ones.
• Don't leak whether a username exists — return the same error for bad user and bad password. UsernameNotFoundException is mapped to BadCredentialsException by default (hideUserNotFoundExceptions=true); keep it that way.
• Rotate signing keys and support key IDs (kid) so you can roll RSA keys without downtime (JWKS makes this automatic for resource servers).
• Prefer resource-server + external IdP over building your own auth server unless you have a strong reason.
• SecurityContextHolder is ThreadLocal.

Interview Questions

@Service
class OrderService {
    @PreAuthorize("hasRole('ADMIN')")
    public void deleteAll() { /* ... */ }
    public void cleanup() { deleteAll(); }   // called from a permitAll endpoint
}

User.withUsername("kai").password("secret").roles("USER").build();