Authentication Interview Questions

Summary

Authentication (authN) verifies who you are; authorization (authZ) decides what you're allowed to do. Authentication happens first and produces an identity; authorization uses that identity (plus roles, attributes and context) to allow or deny each action.

Longer Answer

Logging in with a password or passkey is authentication; checking whether that user may delete an invoice is authorization. HTTP status codes reflect the difference: 401 Unauthorized means 'not authenticated' (despite its name), 403 Forbidden means 'authenticated but not allowed'. Authorization must be enforced on every request on the server, close to the data.

Key Points

• AuthN = identity
• AuthZ = permissions
• 401 vs 403
• Enforce authZ server-side on every request

Summary

Sessions store state on the server and give the browser an opaque session ID cookie; token-based auth gives the client a signed token (often a JWT) containing claims that servers verify without a lookup. Sessions are simpler to revoke; tokens scale statelessly but are hard to revoke before expiry.

Longer Answer

Sessions: server-side store (Redis/DB), HttpOnly cookie, easy logout/revocation, needs CSRF protection, natural for browser apps. JWT: self-contained, good for APIs, mobile and service-to-service, but payload is readable (not encrypted), revocation needs short expiry plus refresh tokens or a denylist, and storing tokens in localStorage exposes them to XSS. Many modern web apps use sessions (or a BFF holding tokens) for browsers and JWTs for machine/API clients.

Key Points

• Sessions: stateful, easy revocation
• JWT: stateless, hard revocation
• Cookies need CSRF defenses
• localStorage tokens are XSS-exposed

Comparison / Tradeoffs

Summary

Accepting alg: none or the wrong algorithm, not validating exp/aud/iss, using weak HMAC secrets, storing tokens in localStorage, putting sensitive data in the payload, very long expiry without revocation, and confusing ID tokens with access tokens.

Longer Answer

Always pin accepted algorithms when verifying, validate standard claims, use strong keys (or asymmetric RS256/EdDSA with JWKS rotation), keep access tokens short-lived (5–15 minutes) and use rotating refresh tokens. The payload is only base64-encoded, so anyone can read it. Validate tokens on every request, not just at the gateway, when services are reachable internally.

Key Points

• Pin algorithms
• Validate exp/aud/iss/nbf
• Strong keys, rotate via JWKS
• Short-lived access tokens
• Payload is not secret

Summary

OAuth 2.0 is an authorization framework for granting an application limited access to an API on a user's behalf (access tokens); OpenID Connect (OIDC) is an identity layer on top of OAuth that adds authentication (an ID token describing the user) and standard user info.

Longer Answer

'Login with Google' is OIDC: the app receives an ID token (who the user is) and optionally an access token (to call Google APIs). Using a bare OAuth access token as proof of login is a classic mistake. Key roles: resource owner (user), client (your app), authorization server (IdP), resource server (API).

Key Points

• OAuth: delegated authorization
• OIDC: authentication + ID token
• Access token ≠ ID token
• Roles: client, authz server, resource server

Summary

The client redirects the user to the authorization server with a code challenge; after login and consent, the server redirects back with a one-time authorization code, which the client exchanges (with the original code verifier) for tokens at the token endpoint. PKCE prevents intercepted codes from being redeemed by attackers.

Longer Answer

Steps: (1) client creates a random code_verifier and its SHA-256 code_challenge, plus state (CSRF) and nonce (OIDC replay protection); (2) redirect to /authorize; (3) user authenticates; (4) redirect back with code and state; (5) client verifies state and POSTs code + verifier to /token; (6) receives access token (+ ID token, refresh token). PKCE is required for public clients (SPAs, mobile) and recommended for all clients in OAuth 2.1. The implicit flow is deprecated.

Code Example

// PKCE values in the browser
const verifier = base64url(crypto.getRandomValues(new Uint8Array(32)));
const challenge = base64url(await crypto.subtle.digest("SHA-256", new TextEncoder().encode(verifier)));

location.href = `${AUTH_URL}/authorize?response_type=code&client_id=${CLIENT_ID}` +
  `&redirect_uri=${encodeURIComponent(REDIRECT)}&scope=openid%20profile%20email` +
  `&code_challenge=${challenge}&code_challenge_method=S256&state=${state}&nonce=${nonce}`;

Key Points

• Code + PKCE for all clients
• state prevents CSRF
• nonce prevents ID token replay
• Implicit flow is deprecated
• Exchange code server-side when possible

Summary

A refresh token is a longer-lived credential used only at the token endpoint to obtain new short-lived access tokens without re-login. Secure it with rotation (each use issues a new one and invalidates the old), reuse detection, binding to the client, secure storage (HttpOnly cookie or secure OS storage) and server-side revocation.

Longer Answer

If a rotated (already used) refresh token is presented again, assume theft and revoke the whole token family. Set absolute and idle lifetimes, revoke on logout and password change, and never send refresh tokens to resource APIs.

Key Points

• Only used at token endpoint
• Rotation + reuse detection
• Secure storage
• Revoke on logout/password change

Summary

Never store plaintext or reversible encryption; store a slow, salted, adaptive hash using Argon2id (preferred), scrypt or bcrypt, and verify with the library's constant-time comparison. Rehash when you raise cost parameters.

Longer Answer

Fast hashes (MD5, SHA-256) allow billions of guesses per second on GPUs; password hashing algorithms are deliberately slow and memory-hard. Salts (handled by the library) defeat rainbow tables; an optional server-side pepper adds protection if only the DB leaks. Also: rate-limit login, check passwords against breached-password lists (HIBP k-anonymity API), and follow NIST guidance (length over complexity rules, no forced periodic rotation).

Key Points

• Argon2id / scrypt / bcrypt
• Unique salt per password
• Constant-time verify
• Breached-password checks
• Rate-limit logins

Summary

MFA requires two or more independent factors: something you know (password), have (device, security key) or are (biometric). Phishing-resistant factors like FIDO2/WebAuthn security keys and passkeys are strongest; TOTP apps are good; SMS codes are weakest due to SIM swapping and phishing.

Longer Answer

Push-notification MFA is vulnerable to fatigue attacks (spamming approvals) unless number matching is used. Provide recovery codes and secure account recovery, which is often the weakest link. Step-up authentication requires re-verification for sensitive actions.

Key Points

• Know / have / are
• Passkeys & security keys are phishing-resistant
• SMS is weakest
• Secure recovery flows
• Step-up auth for sensitive actions

Summary

Set HttpOnly (no JavaScript access), Secure (HTTPS only), SameSite=Lax or Strict (limits cross-site sending), a narrow Path/Domain, sensible expiry, and use the __Host- prefix where possible. Regenerate the session ID on login and privilege change.

Longer Answer

Also enforce idle and absolute timeouts server-side, invalidate sessions on logout and password change, and store minimal data in the session. SameSite=None requires Secure and is needed only for legitimate cross-site use.

Key Points

• HttpOnly, Secure, SameSite
• __Host- prefix
• Regenerate ID on login
• Server-side timeouts and invalidation

Summary

Rate-limit by IP, account and device fingerprint; add progressive delays or temporary lockouts; use bot detection/CAPTCHA after failures; check passwords against breached lists; require MFA; and monitor for distributed attacks (many IPs, many accounts).

Longer Answer

Be careful that lockouts don't enable denial-of-service against specific users; prefer throttling and step-up challenges. Return generic error messages ('invalid email or password') to avoid user enumeration, and keep response timing consistent.

Key Points

• Multi-dimensional rate limits
• Progressive delays, step-up challenges
• Breached-password checks + MFA
• No user enumeration