security
JWT / OAuth2 Resource Server
Validate signed bearer tokens (JWT) at the API boundary so stateless services can trust the identity claims without a session.
In a stateless API — especially a fleet of microservices — keeping server-side sessions is awkward: it requires sticky routing or a shared session store, and it does not scale cleanly. JSON Web Tokens solve this by carrying the identity itself. The client presents a signed token on every request, and the service validates the signature and reads the claims, so it can trust who the caller is without looking anything up or holding any session state.
A passport stamp — issued once by a trusted authority, checked at every border by verifying the stamp's authenticity, no need to call back to the issuing country.
Key Concepts
1
A JWT has three parts: a header, a payload of claims (subject, expiry, issuer, roles), and a signature, all Base64URL-encoded. The signature is the crux — it is computed over the header and payload with either a shared secret (HMAC) or, more commonly for OAuth2, the identity provider's private key (RS256). Configured as an OAuth2 resource server, a Spring service validates each incoming bearer token by checking that signature against the issuer's public key (fetched from a JWKS endpoint), verifying the expiry and issuer, and then mapping the token's claims into a Spring Authentication with authorities — all without a database round trip or a session. The identity provider (Keycloak, Auth0, Cognito, or your own auth server) issues and signs the tokens; the resource server only verifies them.
Authentication
2
The security caveats are what separate a solid answer from a shaky one. The token's payload is signed, not encrypted — it is readable by anyone — so never put secrets in it. Always verify the signature, expiry, and issuer; trusting an unverified token is the classic catastrophic mistake. Because JWTs are stateless they cannot be revoked before they expire, which is why access tokens are kept short-lived and paired with refresh tokens, and why sensitive systems sometimes add a revocation list. HTTPS is mandatory, since a stolen bearer token is enough to impersonate the user.
3
What the interviewer is probing.
What the interviewer is probing.
4
1. "What does a resource server actually do?" *Probing:* the role. *Stalls:* "Issues tokens."
*Moves up:* validates the token and authorises the request — it does not issue tokens, that is the
authorization server.
1. "What does a resource server actually do?"
5
2. "How is a JWT validated?" *Probing:* the mechanism. *Stalls:* "A secret." *Moves up:*
signature against the issuer's public key fetched from the JWKS endpoint, plus issuer, audience and
expiry claims.
2. "How is a JWT validated?"
6
3. "How do scopes become authorities?" *Probing:* the detail. *Stalls:* "Automatically." *Moves
up:* the default converter maps the scope claim to SCOPE_ prefixed authorities, and a custom
converter maps roles from elsewhere in the token.
3. "How do scopes become authorities?"
7
4. "What is the trade against opaque tokens?" *Probing:* the depth. *Stalls:* "None." *Moves
up:* JWTs validate locally with no network call but cannot be revoked; opaque tokens need
introspection per request but are revocable.
4. "What is the trade against opaque tokens?"