HTTP API Authentication Interview Questions

HTTP 401 Unauthorized is specifically used when a request lacks valid authentication credentials or the provided credentials are invalid. RFC 7235 specifies that the response must include a WWW-Authenticate header describing how to authenticate. 400 is for malformed requests generally, 403 is for when the client IS authenticated but lacks permission, and 500 indicates a server-side error.

RFC 6750 defines the OAuth 2.0 Bearer Token usage. The standard method for sending a bearer access token is via the Authorization header with the scheme Bearer followed by a space and the token value, e.g., Authorization: Bearer mF_9.B5f-4.1JqM. This is the recommended approach over alternatives like the request body or URI query parameter.

401 Unauthorized is returned when authentication credentials are missing or invalid. 403 Forbidden is returned when the server recognizes the authenticated identity but that identity does not have permission to access or perform the operation on the resource. This distinction is defined in RFC 7231/9110.

In the authorization code flow, the back-channel token request must include grant_type=authorization_code along with the code and client credentials. client_credentials is for machine-to-machine access without a user, implicit (deprecated) returns a token directly in the front channel without a code exchange, and password (deprecated) sends raw user credentials directly.

A JWT is structured as header.payload.signature. The header (also called the JOSE header) declares the token type and signing algorithm. The payload (also called the claims set) contains the assertions such as iss, sub, and exp. The signature is the cryptographic MAC over the first two segments using the algorithm named in the header, which the receiver verifies to confirm integrity.

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.

Because there's no user involved, the client credentials grant collapses OAuth's multi-step redirect dance into a single request/response: the client presents its credentials directly and gets a token back. RFC 6749 §4.4 restricts it to confidential clients — ones that can hold a secret, i.e. server-side services, never a browser app or mobile app — and says a refresh token normally shouldn't even be issued, since the client can just re-authenticate with its own credentials to get a new access token whenever it needs one.

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.

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.

The client credentials grant (RFC 6749 §4.4) is for exactly this case: "the client is requesting access to the protected resources under its control" with no resource owner involved at all. The client authenticates directly to the token endpoint with its own credentials and receives an access token representing the service itself, not a user — a single request/response exchange with no redirect, no consent screen, and, per the RFC, normally no refresh token, since the client can simply request a new access token with its credentials whenever needed. (a) requires a resource owner authenticating and consenting through a browser redirect — there's no user here. (c) the implicit grant is also user/browser-based — it returns a token via a redirect fragment, which doesn't fit a headless batch job either. (d) still takes an actual end user's password as the grant, just without a redirect; that's a person's credentials, not a service identity.

In session fixation, an attacker gets a victim to start a session with an ID the attacker already knows — for example by sending a link containing a session identifier, or because a pre-login session cookie was already set — then waits for the victim to log in under that same ID. If the application keeps using the pre-existing session ID across the authentication boundary, the attacker's known ID becomes a valid, authenticated session the moment the victim logs in, and the attacker can use it directly. OWASP's Session Management Cheat Sheet states the session ID "must be renewed or regenerated by the web application after any privilege level change," and singles out authentication as the most important trigger. Regenerating the ID at login invalidates whatever ID the attacker was tracking, so the attacker is left holding a dead session while the real user gets a fresh one only they know.

Neither option is unconditionally safer — each closes one door and needs a different defense for the other. A JS-readable bearer token needs a strong XSS defense (output encoding, CSP, avoiding unsafe HTML-injection sinks) since XSS is fully game-over for it; an ambient cookie needs CSRF defenses (SameSite plus, for state-changing routes, a CSRF token) since XSS is not required to abuse it. Teams sometimes combine both: an HttpOnly refresh-token cookie plus a short-lived, memory-held access token, to keep the long-lived credential off the JS-readable surface while accepting the smaller blast radius of a short-lived token being exposed.

RFC 7519 §4.1.4 mandates that JWT processors MUST reject tokens where the current time is at or after the exp value. RFC 6750 §3.1 specifies that an expired token is an invalid_token error and the resource server MUST respond with HTTP 401 and a WWW-Authenticate header carrying error="invalid_token". The azp claim (authorized party) is checked by the client, not required by the resource server for basic validation. The aud as a URI is perfectly valid per RFC 7519 §4.1.3. RFC 7519 does acknowledge that implementors may allow small clock skew, but it is not a default tolerance, and 'MUST reject' takes precedence — accepting is never the correct answer once past exp.

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.

RFC 7636 exists because "OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack" — public clients like native/mobile apps can't hold a secret the way a confidential server-side client can, so anyone who intercepts the code (e.g. a malicious app claiming the same custom URI scheme) could otherwise redeem it directly. PKCE closes that gap without a shared secret: before redirecting, the client generates a random code_verifier, derives a code_challenge from it (normally SHA-256, method S256), and sends the challenge with the authorization request. The token endpoint later requires the original code_verifier, checks it against the stored challenge, and rejects the exchange if it doesn't match. An attacker who only has the intercepted code — not the verifier, which never left the legitimate app until the token request — cannot complete the exchange. (a) mischaracterizes PKCE as encryption; it's a proof-of-possession check, not confidentiality. (c) picks the wrong grant type — client credentials has no user and no redirect at all, so it can't drive a user-delegated mobile flow. (d) is a real complementary practice but is not what PKCE itself does.

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.

SameSite=Lax is a middle ground, not full cross-site blocking: it withholds the cookie on cross-site subrequests (images, fetches, iframes) but explicitly still allows it on a top-level cross-site navigation using a "safe" method, which includes GET. That carve-out exists so ordinary cross-site links keep working while logged in — but it means any endpoint that changes state on GET (a legacy pattern, but real: logout links, one-click unsubscribe, some old admin toggles) is still exploitable via a plain <a href> or auto-submitting redirect, because the browser happily attaches the cookie to that top-level GET. SameSite=Strict closes this gap by withholding the cookie on cross-site navigation entirely, at the cost of the cookie also being absent immediately after a user clicks in from another site. The practical takeaway: Lax is a solid baseline, but state-changing operations must still use POST/PUT/DELETE, never GET, and high-value endpoints still want a CSRF token as defense in depth — Lax was never meant to be a complete CSRF solution on its own.

Rotation means every use of a refresh token issues a new one and invalidates the one just used, so under normal operation each refresh token is presented exactly once. A second presentation of an already-invalidated token means either the legitimate client and an attacker both have a copy, or the attacker got there first — in either case, something is compromised. RFC 9700 (OAuth 2.0 Security Best Current Practice, §4.14) directs that this reuse be treated as a compromise signal and that the server revoke not just the reused token but the whole token family descended from a common ancestor, so a token an attacker is holding — rotated or not — stops working, forcing re-authentication. Silently rejecting just the one reused request and leaving the rest of that lineage valid would let an attacker who already rotated forward once keep using their newer token undetected.

Nothing in this handler ever issues a new session ID at the point of authentication — it just writes userId and authenticated onto whatever session (and therefore whatever session ID) the request already carried, which could be one the attacker set on the victim's browser before login, whether via a fixation link or simply an existing pre-login cookie the attacker also holds. Once the victim authenticates, that same, attacker-known session ID becomes a valid authenticated session, and the attacker can use it directly without ever learning the victim's password. The fix is to regenerate the session — issue a brand-new session ID, migrating over only the data you intend to keep — right after credentials are verified and before marking the session authenticated, e.g. req.session.regenerate(...) in Express, or the framework's equivalent. (b) describes a real but different timing-attack concern about comparing credentials, unrelated to session identity. (c) a plain-text response body has no bearing on which session ID gets used. (d) a missing null check would cause a crash on malformed input, not a session-fixation vulnerability — a different bug class entirely.

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.

This is RFC 9700's (OAuth 2.0 Security Best Current Practice) guidance in §4.14: rotating refresh tokens converts them from a long-lived bearer secret into a chain where only the most recent link is valid, and reuse of an earlier link is a reliable compromise signal precisely because legitimate clients never present the same refresh token twice. Revoking the whole family, not just the reused token, matters because an attacker who already rotated forward once — using the stolen token before the legitimate client did — is now holding a different, currently-valid refresh token; revoking only the specific token that got reused would leave that attacker's newer token untouched.

PKCE inserts exactly two things into the ordinary authorization-code flow: a challenge generated and sent before the redirect, and a verifier sent and checked at the token exchange — everything else (the redirect to the authorization server, user consent, the code coming back, the client finally calling the resource API) is unchanged from the plain flow. The ordering is what makes it secure: the verifier is only ever transmitted once, at the very end, over the trusted token-endpoint channel — never in the front-channel redirect where it, like the authorization code itself, could be intercepted. If a copy of the code leaks from the redirect step, whoever has it still lacks the verifier generated in step one and held by the legitimate client, so the exchange fails for them.

The SPA is a public client (its JS bundle is entirely inspectable, so it cannot hold a secret) that needs delegated, user-consented access to another service — that's precisely the authorization code flow's use case, and PKCE is what makes it safe for a client that can't hold a client_secret: the browser redirects to the third party's consent screen, gets a code back, and the SPA exchanges that code with a code_verifier instead of a secret. (b) is wrong on two counts: client credentials has no user consent at all (it authenticates the app, not the user, so it can't act "on behalf of the signed-in user"), and any secret shipped in browser JavaScript is trivially extractable — never embed one client-side. (c) is the password anti-pattern OAuth was invented to replace: it hands your app the user's actual third-party password, far broader access than the API scope you need. (d) — the implicit grant returns the access token directly in the redirect URI fragment with no code-exchange step, exposing it to browser history and referrer leakage; current OAuth security guidance recommends authorization code with PKCE over implicit for browser-based apps specifically because of this exposure.

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.