Security in Pictures

A hotel: the front desk checks your ID (who are you?), then gives a key card that opens only your room (what may you do?).

1. Guest shows ID at the front desk → identity checked (authentication).
2. Desk issues a key card listing what the guest may open (authorization data).
3. Card opens Room 101 → allowed.
4. Card on Room 205 → refused: known guest, no permission (403).

In Spring: Authentication filters + AuthenticationManager answer step 1; AuthorizationFilter with hasAuthority(...) answers steps 3–4.

Say it in the interview: Authentication proves who you are (401 on failure); authorization decides what you may do (403 on failure).

An airport: every passenger walks through checkpoints in a fixed order before reaching the gate. Your controller is the gate.

1. Request enters Tomcat; DelegatingFilterProxy hands it to Spring's FilterChainProxy.
2. SecurityContextHolderFilter prepares an empty identity for this request.
3. BearerTokenAuthenticationFilter reads the JWT and verifies it; failure → 401.
4. ExceptionTranslationFilter turns security failures into 401 or 403.
5. AuthorizationFilter checks the rule (e.g. SCOPE_payment.write); pass → controller.

In Spring: Several chains can exist; @Order + securityMatcher decide which one handles a URL (your Auth Server has two).

Say it in the interview: Security is a chain of servlet filters in front of the DispatcherServlet; rejected requests never reach the controller.

A gym: you show your membership once at the entrance, get a wristband, and the staff just check the wristband after that.

1. Browser posts username and password to /login.
2. UserDetailsService loads the user; PasswordEncoder compares the hash.
3. Server creates an HTTP session and stores the identity in it.
4. Browser sends the session cookie on every next request; no password needed.

In Spring: formLogin() adds UsernamePasswordAuthenticationFilter; your Auth Server uses this for nithin before the consent screen.

Say it in the interview: Form login is stateful: identity lives in a server session, and a cookie points to it — which is why CSRF protection matters here.

A sealed envelope: anyone can read the letter through the window, but only the issuer's wax seal proves nobody changed it.

1. Auth Server signs header + payload with its private key.
2. Client sends the token to the API as Authorization: Bearer.
3. API recomputes the check with the public key → matches → trust the claims.
4. Someone edits the payload → signature no longer matches → 401.

In Spring: Resource server: JwtDecoder (from issuer-uri) verifies signature, iss and exp; public key comes from /oauth2/jwks.

Say it in the interview: A JWT is Base64-encoded, not encrypted; its security is the signature, so never put secrets in the payload.

"Log in with IDHub" on a shopping app: you type your password only on IDHub's page; the app gets a code, then trades it for a token behind the scenes.

1. App redirects the browser to /authorize with client_id, scope, redirect_uri and a PKCE code_challenge.
2. User signs in on the provider's own page (the app never sees the password).
3. User approves scopes; provider redirects back with a one-time CODE (not a token).
4. Browser hands the code to the app's backend.
5. Backend calls /token with code + code_verifier + its client secret (server-to-server).
6. Provider checks everything and returns the access token.
7. Backend calls the API with Authorization: Bearer; the API validates it and returns the data.

In Spring: Your project: Postman = app, :9000 = provider, Service A/B = API. Auth Server beans ①–⑦ handle steps 1–6; Service A/B do step 7.

Say it in the interview: Your image shows the token coming back at step 3; in Authorization Code the browser only gets a code, and the token comes on the back channel (steps 5–6). Token-in-the-browser was the old implicit flow, now deprecated.

A delivery van with a company badge: nobody logs in; the van shows its own badge at the gate every night.

1. Job sends its own client_id + secret to /oauth2/token (one call, no browser).
2. Auth Server checks the client, grant and scopes; returns a token with sub = the client.
3. Job calls the API with the token.
4. API checks signature and scope like any other token.

In Spring: Job side: spring-boot-starter-oauth2-client + AuthorizedClientServiceOAuth2AuthorizedClientManager (no HTTP request in a scheduler).

Say it in the interview: Use the user's token when a user acts; use client credentials when the application acts by itself.

A shop checks banknotes with a UV lamp it bought once from the central bank, instead of phoning the bank for every note.

1. On the first request, Service A reads the issuer's metadata and downloads the public key set.
2. Service B does the same, independently.
3. Every later request is verified locally with the cached key; the Auth Server isn't called.

In Spring: spring.security.oauth2.resourceserver.jwt.issuer-uri=http://localhost:9000 — Spring finds /.well-known/openid-configuration, then jwks_uri.

Say it in the interview: That's why an Auth Server outage doesn't break existing tokens, and why a restarted Auth Server (new key) makes old tokens fail.

A signed permission slip passed from the front office to the back office: the back office checks the same signature itself.

1. Client calls Service A with the user's JWT.
2. A validates it, then its WebClient copies the same JWT from the SecurityContext onto the call to B.
3. B validates it again and saves the payment; B still knows the user is nithin.

In Spring: ServletBearerExchangeFilterFunction (MVC) or ServerBearerExchangeFilterFunction (WebFlux) on A's WebClient.

Say it in the interview: Defense in depth: B trusts nobody by network position; even a direct call to B needs a valid token.

Club door: no ID → turned away (401). ID fine but VIP room only → turned away from that room (403).

1. No token → authentication fails → 401 with WWW-Authenticate: Bearer.
2. Valid token without payment.write → authorization fails → 403.
3. Valid token with payment.write → 201.

In Spring: ExceptionTranslationFilter: AuthenticationEntryPoint → 401, AccessDeniedHandler → 403. Customize both for clean JSON bodies.

Say it in the interview: 401 means 'I don't know who you are'; 403 means 'I know you, but you're not allowed'.

A day pass (access token) expires every hour; a membership card (refresh token) at the desk gets you a new day pass without re-registering.

1. App calls the API with an expired access token.
2. API returns 401 (expired).
3. App sends the refresh token to /oauth2/token (never to APIs).
4. Auth Server returns a new access token (often a new refresh token too: rotation).
5. App retries the call; the user notices nothing.

In Spring: Auth Server: add AuthorizationGrantType.REFRESH_TOKEN to the client; TokenSettings.refreshTokenTimeToLive(...). Not used for client credentials.

Say it in the interview: Short access token for safety, long refresh token for convenience; the refresh token only ever goes to the Auth Server.

Someone slips a pre-signed withdrawal form into your pile of mail; the bank accepts it because it carries your signature stamp (the cookie).

1. User is logged into the bank; the browser holds its session cookie.
2. A malicious page auto-submits a form to the bank; the browser attaches the cookie automatically.
3. Without a CSRF token the bank can't tell it apart from a real request; with one, it rejects it (403).

In Spring: On by default. Your A and B disable it because they use Bearer tokens in a header, which browsers never attach automatically.

Say it in the interview: CSRF exploits automatic cookies; APIs authenticated by an Authorization header aren't exposed, so stateless APIs can turn it off.

A security guard at the building door phones the other office: 'Visitor from shop.com — do you accept them?' Only a yes lets them in.

1. JavaScript on shop.com calls api.pay.com (different origin).
2. Browser first sends an OPTIONS preflight with the Origin header.
3. API answers with Access-Control-Allow-Origin (and allowed methods/headers).
4. Browser sends the real request if allowed, or blocks it in the console.

In Spring: http.cors(...) + a CorsConfigurationSource bean. Postman and server-to-server calls ignore CORS; only browsers enforce it.

Say it in the interview: CORS is enforced by the browser, not the server; it protects users, and it's not a replacement for authentication.