HTTP & API JWT Interview Questions

The Authorization Code flow with PKCE is the current OAuth 2.0 Security Best Current Practice (RFC 9700) recommendation for SPAs, native apps, and other public clients that cannot keep a client secret confidential. PKCE replaces the client secret with a dynamically generated code verifier/challenge pair, preventing an attacker from intercepting the authorization code and exchanging it for a token. The Implicit grant is deprecated because it exposes tokens in the URL fragment and offers no client authentication. The Resource Owner Password Credentials grant is deprecated because it requires the app to handle user passwords directly. The Client Credentials grant is for machine-to-machine communication where the client is acting on its own behalf, not on behalf of a user.

Line 2 reads the header named "Authentication", but the standard HTTP header for bearer credentials is Authorization. Since no Authentication header is sent, auth is None, the if guard fails, and the function returns None. Changing the header name to "Authorization" fixes the extraction.

RFC 6750 defines the standard method for transmitting OAuth 2.0 bearer tokens: the client places the access token in the Authorization header using the Bearer authentication scheme, formatted as Authorization: Bearer <access_token>. While HTTP header names are case-insensitive per RFC 7230, the Bearer scheme name itself is case-sensitive per RFC 6750. This is the preferred and most secure of the three methods defined in RFC 6750 (the others being URI query parameter and form-encoded body parameter, both of which have security drawbacks such as logging exposure).

A signed JWT (JWS) has three Base64URL-encoded segments: header, payload, and signature. The payload segment is only Base64URL-encoded, NOT encrypted. Anyone who obtains the token can Base64URL-decode the payload and read all claims such as sub, exp, and roles. The signature segment only provides integrity — it proves the token was issued by someone holding the signing key and was not tampered with. To keep claims confidential, you must use an encrypted JWT (JWE), which is a different and separate specification (RFC 8317) from a signed JWT (JWS, RFC 7515). Most OAuth 2.0 access tokens formatted as JWTs are JWS, not JWE, so their payloads are readable by design.

A signed JWS-format JWT is not encrypted — the header and payload are only Base64URL-encoded and anyone can decode and read the claims. The signature proves integrity and authenticity: that a party holding the signing key produced it and nobody altered it. It does not provide confidentiality (use JWE for that) and does not by itself prevent replay (use exp, jti, and TLS).

JWT = header.payload.signature, each Base64URL-encoded. The signature provides integrity and authenticity (not confidentiality — a signed JWT is readable by anyone). Self-contained claims like exp let servers validate tokens statelessly, but also mean a token can't be revoked before it expires without extra infrastructure (a denylist or short lifetimes plus refresh tokens).

A signature only proves the token was issued by the holder of the signing key and hasn't been tampered with (RFC 7519 §4.1) — it says nothing about whether the token is still within its validity window or intended for this service. Verification must also check exp (MUST NOT be accepted at or after this time, with a small clock-skew tolerance permitted), nbf if present, that iss matches the expected issuer, and that aud names this service — RFC 7519 says a recipient not identified in aud should reject the JWT. Skipping this is exactly how the prompt's bug happens: a legitimately-issued token for a different service gets replayed here, or an expired token close to real time keeps being honored. (c) and (d) touch signing-algorithm strength, not claims validation, and neither would have caught an expired, wrong-audience token.

CSRF exploits the fact that browsers attach cookies automatically to any request to the target origin, regardless of which page triggered it. SameSite=Strict/Lax (a) directly targets that: the browser withholds the cookie on the cross-site requests each setting covers, so a forged cross-site POST from an attacker's page arrives with no session cookie at all. A CSRF token (b) works differently but is equally effective: the attacker's page can't read or set a value it never received — the same-origin policy blocks reading responses, and a synchronizer or signed double-submit token is unpredictable and bound to the user's session — so a forged request is missing it or carries the wrong one and gets rejected. HttpOnly (c) is a real, valuable defense but against a different threat: it stops injected JavaScript (XSS) from reading and exfiltrating the cookie. It does nothing to stop the browser's normal, automatic attachment of the cookie to a cross-site request, which is the entire CSRF mechanism, so relying on HttpOnly alone leaves CSRF wide open. Rotating a JWT signing key (d) is unrelated to cookie-based session auth's CSRF exposure entirely — it limits the blast radius of a compromised key, not forged requests riding a legitimately ambient cookie.

PKCE (RFC 7636) exists because OAuth 2.0 public clients using the authorization code grant are "susceptible to the authorization code interception attack" — without a client secret to prove identity at the token endpoint, anyone who intercepts the code can redeem it. The verifier/challenge pair acts as a one-time, client-generated substitute for a secret: the challenge (sent up front) is a one-way function of the verifier (sent only at the end), so binding the code to the challenge lets the token endpoint confirm the same client that started the flow is the one finishing it, without ever transmitting a reusable shared secret. This matters most for mobile/native apps, where OS-level redirect interception is a real risk, and for SPAs, whose JS is fully inspectable so no secret is truly private — current OAuth security guidance recommends PKCE for all authorization-code clients, confidential or public, as defense in depth.

The function lets the token itself dictate which algorithm verifies it (header.alg) instead of the server hardcoding the one algorithm it actually issues tokens with. This is the classic JWT "algorithm confusion" flaw: if the server expects asymmetric RS256 (signed with a private key, verified with a public key) but the verification code will run whatever crypto.verify supports for header.alg, an attacker can set alg to HS256 (a symmetric HMAC algorithm) and sign the token using the server's own public key as the HMAC secret — which is, by definition, not secret at all, since it's meant to be shared. Many JWT libraries' generic "verify with whatever alg is in the header" entry point makes this mistake easy to write; some implementations go further and also accept alg: "none", which has no signature at all, so any payload is accepted outright. The fix is to never let the token choose its own verification algorithm: pin the expected algorithm (e.g. always verify as RS256 with the known public key) at the call site, and reject any token whose header doesn't match. (b) parsing before verifying is standard practice (you need the header to know things like kid) and by itself introduces no forgery path. (c) an error message describing only "invalid signature" leaks essentially no attacker-useful information — a real but minor hardening nitpick, not what enables forgery. (d) a malformed token would just throw during parsing before reaching a security-relevant check — a crash on bad input is a different bug class from accepting a forged-but-well-formed token as valid.