Skip to content

Authentication Interview Questions

These authentication interview questions cover JWTs, sessions, OAuth, cookies, CSRF, and password hashing—the core building blocks of secure web login systems.

Authentication Interview Overview

Authentication proves who a user is; authorization decides what they can do. Interviews often blur the two, so clarify identity verification (credentials, tokens, MFA) separately from permission checks (roles, scopes, policies). Modern web apps combine HTTP-only cookies or bearer tokens with server-side validation on every protected request.

Strong answers explain threat models: stolen tokens, XSS, CSRF, credential stuffing, and session fixation. You should describe how bcrypt or Argon2 stores passwords, why JWTs are signed but not encrypted by default, and when OAuth delegates identity to a provider without handing your app the user's password.

Authentication Interview Cheatsheet

Quick answers you can expand in a real interview.

Topic Short answer
Password hash bcrypt/Argon2 with salt and work factor; never store plaintext.
JWT Signed claims (sub, exp); verify signature and expiry on every request.
Session cookie Opaque id in httpOnly, secure, SameSite cookie; state on server.
OAuth 2.0 Authorization framework; use Authorization Code + PKCE for SPAs.
CSRF Cross-site forged requests; mitigate with SameSite cookies or CSRF tokens.
Refresh token Long-lived token to obtain new access tokens; rotate and revoke on logout.

15 Authentication Interview Questions with Answers

Use the short version first, then offer trade-offs if the interviewer wants depth.

1. What is the difference between authentication and authorization?

Authentication establishes identity—proving the caller is who they claim to be via password, token, or SSO. Authorization runs after authentication to decide whether that identity may perform an action on a resource. A valid JWT authenticates the user; role or scope checks on the endpoint authorize the operation.

2. How should passwords be stored in a database?

Never store plaintext or reversible encryption. Hash with a slow, adaptive algorithm like bcrypt or Argon2, which embeds a unique salt per password. Tune the work factor so hashing takes tens to hundreds of milliseconds. On login, hash the submitted password with the stored salt and compare using a constant-time function.

3. What is a JWT and what should you verify when accepting one?

A JSON Web Token is a compact, signed set of claims (header.payload.signature). Verify the signature with the correct secret or public key, check exp and nbf, validate iss and aud if used, and confirm the token has not been revoked if you maintain a denylist. JWTs authenticate statelessly but are not encrypted unless you use JWE.

4. Compare session-based auth with JWT-based auth.

Session auth stores state server-side (or in Redis) and sends an opaque session id in an httpOnly cookie; revocation is immediate by deleting the session. JWT auth embeds claims in the token; servers verify signature without a lookup but cannot easily revoke until expiry unless you add a blocklist or short-lived access tokens with refresh rotation.

5. What cookie flags are important for session security?

Set HttpOnly so JavaScript cannot read the session token (mitigates XSS token theft). Secure sends the cookie only over HTTPS. SameSite=Lax or Strict reduces CSRF risk by limiting cross-site sends. Use a sensible Path and Domain scope so cookies are not leaked to unrelated subdomains.

6. Explain the OAuth 2.0 Authorization Code flow with PKCE.

The client generates a code_verifier and code_challenge, redirects the user to the provider's authorize URL, and receives an authorization code on callback. It exchanges the code plus verifier for access (and often refresh) tokens. PKCE protects public clients like SPAs and mobile apps that cannot keep a client secret.

7. What is CSRF and how do you prevent it?

Cross-Site Request Forgery tricks a browser into sending authenticated cookies to your site from another origin. Mitigations include SameSite cookies, synchronizer CSRF tokens in forms and APIs, and checking Origin/Referer headers for state-changing requests. Double-submit cookies are another pattern for SPA + cookie auth.

8. How does XSS interact with authentication design?

If an attacker injects script, they can exfiltrate tokens stored in localStorage or perform actions as the user. Prefer httpOnly cookies for session tokens so JS cannot read them. Still sanitize output, use CSP, and keep access tokens short-lived because XSS can trigger authenticated requests even without reading cookies.

9. What are access tokens vs refresh tokens?

Access tokens are short-lived credentials sent with API calls—often 5–15 minutes. Refresh tokens are longer-lived, stored more securely, and used only at a token endpoint to mint new access tokens. Rotate refresh tokens on use and invalidate families on theft detection to limit blast radius.

10. How would you implement logout with JWTs?

Pure stateless JWTs cannot be truly revoked until expiry unless you maintain a server-side denylist or token version on the user record. Practical approach: short access token TTL, delete refresh token server-side on logout, and optionally bump a tokenVersion claim checked on each request. For sessions, simply destroy the server session.

11. What is multi-factor authentication (MFA) and common factors?

MFA requires two or more factors: something you know (password), have (TOTP app, hardware key), or are (biometric). TOTP (RFC 6238) generates time-based codes from a shared secret. WebAuthn/FIDO2 uses public-key cryptography bound to the device, resisting phishing better than SMS OTP.

12. What is the difference between OpenID Connect and OAuth 2.0?

OAuth 2.0 is authorization—delegated access to APIs via scopes. OpenID Connect adds an identity layer on top: an id_token (JWT) with standard claims like sub and email proves who logged in. Use OIDC when you need profile information; use OAuth alone when you only need API access on behalf of a user.

13. How do you protect against credential stuffing and brute force?

Rate-limit login attempts by IP and account, introduce exponential backoff, and require CAPTCHA after failures. Detect breached passwords with Have I Been Pwned APIs, enforce MFA for sensitive accounts, and log anomalous geo or device signals. Generic error messages ("invalid credentials") avoid user enumeration.

14. Where should you validate tokens in a Node.js Express app?

Use authentication middleware early in the chain: extract Bearer token or session cookie, verify signature/expiry or load session, attach req.user, then call next(). Protected routes sit behind this middleware; authorization checks (roles) run in route handlers or a second middleware. Never trust client-sent user ids without verification.

15. What is session fixation and how do you prevent it?

An attacker sets a victim's session id before login so both share the same session after authentication. Regenerate the session id on successful login (and privilege elevation) so the pre-login id becomes useless. Store sessions server-side and bind optional device fingerprinting for high-risk apps.

Common Mistakes

  • Storing JWTs in localStorage while claiming the app is XSS-safe.
  • Using MD5 or SHA-256 alone for password storage without salt and adaptive cost.
  • Skipping PKCE on SPA OAuth flows because "we use HTTPS."
  • Returning different error messages that reveal whether an email is registered.

Key Takeaways

  • Separate authentication (identity) from authorization (permissions).
  • Prefer httpOnly, Secure, SameSite cookies or short-lived tokens with refresh rotation.
  • Threat-model XSS, CSRF, and token theft—not just password strength.
  • OAuth/OIDC delegate login; still validate tokens and scopes on your API.

Pro Tip

When asked to design login, state your storage choice (session vs JWT), cookie flags, CSRF strategy, and one revocation story. Interviewers reward concrete trade-offs over buzzwords.