Tokens, OAuth2 PKCE, Web Attacks & API Security — Interview Questions
Rotating JWT signing keys, the refresh-token flow and rotation, PKCE and implementing OAuth2 PKCE, preventing XSS, the CSRF double-submit cookie, HMAC and request signing, replay-attack protection, RBAC vs ABAC, and API security best practices — with Spring Security configuration and code.
Published September 25, 2026
How to use this lesson
The basics (JWT structure, the OAuth2 authorization-code grant, CORS, CSRF in Spring Security, token invalidation) were covered in the earlier tiers. Here the focus is the senior layer:
key and token lifecycle (rotation, revocation);
public-client security (PKCE);
browser attack classes (XSS, CSRF);
message integrity (HMAC, replay protection);
authorisation models.
Always name the attack, the control, and where it's enforced.
Use asymmetric keys (RS256 or ES256): the auth server signs with the private key; resource servers verify with the public keys, published at a JWKS endpoint (/.well-known/jwks.json).
Each token header carries a kid (key ID) that tells verifiers which key to use.
The rotation process (overlap, then retire):
Generate the new key pair, and publish its public key in the JWKS alongside the old one.
Wait until the verifiers have refreshed their JWKS caches.
Start signing new tokens with the new key.
Keep the old public key in the JWKS until all tokens signed with it have expired (the maximum token lifetime), then remove it.
Automate it (scheduled rotation, for example every 30–90 days), keep the private keys in a KMS or HSM, and have an emergency rotation runbook for a compromised key (this invalidates all tokens immediately).
Spring Security's resource server (spring.security.oauth2.resourceserver.jwt.jwk-set-uri) caches the JWKS, and refetches it when it sees an unknown kid.
Common trap: using a shared HMAC secret (HS256) across many services. Every service that can verify tokens can also forge them, and rotation means redeploying the secret everywhere. Use asymmetric keys for multi-service systems.
Q2. What is the refresh-token flow?
Short answer:
The auth server issues a short-lived access token (5–15 minutes) and a long-lived refresh token (hours to days).
The client calls APIs with the access token. When it expires (a 401, or proactively before the expiry), the client sends the refresh token to the token endpoint (grant_type=refresh_token), and gets a new access token (and, with rotation, a new refresh token).
Security measures:
refresh-token rotation: each refresh token can be used once; if an old one is reused, that indicates theft, so revoke the whole token family;
store the refresh tokens server-side (or as a hashed reference), so they're revocable (logout, password change);
bind them to the client (client authentication for confidential clients; sender-constrained tokens with DPoP or mTLS for high security);
browsers: keep the tokens out of JavaScript-accessible storage; use the BFF pattern (the server holds the tokens; the browser holds an HttpOnly, Secure, SameSite cookie);
absolute session lifetimes (re-authentication after N days).
Q3. What is PKCE? How do you implement OAuth2 PKCE?
Short answer:
PKCE (Proof Key for Code Exchange, RFC 7636) protects the authorization code flow against code interception: a malicious app or a leaked redirect could steal the authorization code and exchange it for tokens.
How it works:
The client creates a random code_verifier (43–128 characters), and computes code_challenge = BASE64URL(SHA256(code_verifier)).
The authorization request includes code_challenge and code_challenge_method=S256.
The auth server stores the challenge with the issued code.
At the token exchange, the client sends the code_verifier; the server hashes it and compares. A stolen code is useless without the verifier.
Where to use it: originally for public clients (mobile apps, SPAs, which can't keep a client secret). OAuth 2.1 and current best practice require PKCE for all clients, including confidential ones. The implicit flow is deprecated.
In Spring:
Spring Authorization Server requires PKCE for public clients (and it can be required for all clients, with requireProofKey(true));
on the client side, Spring Security's OAuth2 client applies PKCE automatically for public clients, and can be configured for confidential ones with OAuth2AuthorizationRequestCustomizers.withPkce().
Short answer:XSS (cross-site scripting) is when attacker-controlled input is rendered as executable script in other users' browsers. It can steal tokens, act as the user, or deface pages. There are stored, reflected and DOM-based variants.
Output encoding by context (the main defence): encode HTML body, attributes, JavaScript, URLs and CSS differently. Use auto-escaping templates (Thymeleaf th:text, React JSX escape by default); avoid th:utext, dangerouslySetInnerHTML and innerHTML with untrusted data.
Sanitise rich HTML with an allow-list (the OWASP Java HTML Sanitizer, DOMPurify on the client) where users must submit HTML.
Content Security Policy (a strong CSP: script-src 'self' with nonces or hashes, no unsafe-inline) limits the damage of any XSS that gets through.
HttpOnly cookies, so scripts can't read the session cookie; avoid storing tokens in localStorage.
Validate input (type, length, format) as defence in depth, but don't rely on input filtering alone.
APIs: return the correct Content-Type (application/json), plus X-Content-Type-Options: nosniff.
Common trap: the old X-XSS-Protection header is obsolete. Modern browsers removed the XSS auditor, and the header can even introduce issues. Use CSP instead. (Spring Security now sets X-XSS-Protection: 0 by default.)
Q5. What is the CSRF double-submit cookie pattern?
Short answer:
CSRF (cross-site request forgery) tricks a logged-in user's browser into sending a request (with its cookies) to your site from an attacker's site.
The double-submit cookie is a stateless CSRF defence: the server sets a random token in a cookie (readable by JavaScript, so not HttpOnly); the client copies it into a request header (for example X-XSRF-TOKEN) on state-changing requests; the server checks that the header matches the cookie. An attacker's site can make the browser send the cookie, but can't read it (same-origin policy), so it can't set the matching header.
Hardening: use the signed double-submit variant (an HMAC of the token bound to the session), because an attacker who controls a subdomain can sometimes plant cookies. Use __Host- cookie prefixes and SameSite cookies as an extra layer.
In Spring Security:CookieCsrfTokenRepository.withHttpOnlyFalse() implements this pattern (which Angular's XSRF-TOKEN convention uses). The default is the synchronizer token pattern, with the token stored in the session.
When CSRF protection isn't needed: pure stateless APIs authenticated with a bearer token in the Authorization header (browsers don't attach that automatically). It is needed whenever you authenticate with cookies, including BFFs.
Q6. What is HMAC? How do you handle replay attacks?
Short answer:
HMAC (Hash-based Message Authentication Code) is HMAC(key, message), using a hash function such as SHA-256. It proves integrity and authenticity: only someone with the shared secret can produce a valid tag. Uses include webhook signatures, API request signing (like AWS SigV4), and signed cookies or tokens.
Verify with a constant-time comparison (MessageDigest.isEqual), to avoid timing attacks.
Replay attacks: an attacker resends a valid, captured request (a payment, a webhook). The signature is still valid, so you need extra controls:
include a timestamp in the signed content, and reject requests outside a short window (for example ±5 minutes);
include a nonce or request ID, and store the seen nonces (in Redis, with a TTL equal to the window), rejecting duplicates;
use idempotency keys for state-changing operations (a replay does no extra harm);
TLS everywhere (it prevents capture in transit);
short-lived, sender-constrained tokens (DPoP, mTLS-bound), so stolen tokens can't be replayed from elsewhere;
one-time codes (authorization codes, OTPs) are invalidated after use.
RBAC (role-based access control): permissions are attached to roles, and users get roles (RESERVATION_AGENT can booking:write). It's simple, auditable, and fits most applications. Its limit is role explosion when access depends on context (a role per hotel per department…).
ABAC (attribute-based access control): decisions are policies over attributes of the subject (department, clearance, tenant), the resource (owner, hotel, classification), the action, and the environment (time, location, device). For example: "agents can modify bookings of their own hotel, during their shift". It's flexible and fine-grained, but more complex to manage and audit.
In practice, combine them: coarse RBAC at the gateway or controller, plus resource-level checks (ownership, tenant) in the service. Alternatives include ReBAC (relationship-based, Google Zanzibar style: OpenFGA, SpiceDB) for sharing models.
In Spring:
@PreAuthorize("hasRole('ADMIN')") for RBAC;
@PreAuthorize("@bookingPolicy.canEdit(authentication, #id)") or a custom AuthorizationManager for ABAC;
externalised policy engines (OPA/Rego, Cedar) for central policies.
Short answer: Use the OWASP API Security Top 10 as a checklist:
Authentication: standard protocols (OAuth2, OIDC); short-lived tokens; validate the iss, aud, exp claims and signature on every service; MFA for users.
Authorisation on every request, at the object level:broken object-level authorisation (BOLA/IDOR) is the top API risk. Check that the caller may access this specific resource, and this specific field (avoid mass assignment by using DTOs, not entities).
Input validation: Bean Validation, size limits, allow-lists; parameterised queries (no SQL injection); safe deserialisation; SSRF protection for URL inputs.
Transport: TLS 1.2+ everywhere (mTLS between services); HSTS.
Minimal data exposure: return only the needed fields; no stack traces or internal details in errors (RFC 7807 problem details).
Secrets: in a vault, never in code or logs; rotate them.
Inventory and lifecycle: document every API (OpenAPI); retire old versions; no forgotten test endpoints (Actuator endpoints secured or not exposed).
Monitoring: audit logs; anomaly detection; alerts on authentication failures and unusual access patterns.
In the pipeline: SAST, dependency scanning (SCA), DAST and API fuzzing, and penetration tests.
Follow-up questions this topic invites — and their answers
Q: Why is the implicit flow deprecated?
A: It returned tokens directly in the URL fragment, exposing them to browser history, referrers and injected scripts, with no way to bind them to the client. Authorization code + PKCE provides the same public-client support far more safely.
Q: Is a JWT encrypted?
A: A standard signed JWT (JWS) is only Base64URL-encoded; anyone can read the payload. Use JWE for encryption, or keep sensitive data out of tokens.
Q: What is DPoP?
A: Demonstrating Proof of Possession: the client signs each request with a private key bound to the token, so a stolen access token can't be used by another party.
Q: What's the difference between authentication and authorisation failures in HTTP?
A: 401 Unauthorized means the request isn't authenticated (missing or invalid credentials); 403 Forbidden means the caller is authenticated but not allowed to perform the action.
