Authentication Interview Questions for Node.js

Authentication Interview Questions for Node.js

Interviewers ask these auth questions often. Here are concise answers for Node.js.

Q1: How does JWT auth work?

On login, sign a token with jwt.sign({ userId }, secret, { expiresIn }). Store in an httpOnly cookie. On each request, verify with jwt.verify(token, secret) in an auth middleware. Set req.user from the payload. The server is stateless; no session store.

Q2: Where should you store JWT?

In an httpOnly, secure, sameSite cookie for web apps. In secure storage (Keychain, Keystore) for mobile. Never in LocalStorage (open to XSS).

Q3: How do you revoke a JWT?

Use short expiry (15 min) so the window is small. For real revocation, use a refresh token (stored in DB) and delete it on logout. Without refresh tokens, you need a blacklist (defeats stateless).

Q4: What is the difference between 401 and 403?

401 Unauthorized means not authenticated (no token or invalid token). 403 Forbidden means authenticated but not authorized (wrong role). Check auth first, then authorization.

Q5: How do you handle password hashing?

Hash with bcrypt (10-12 rounds) or argon2id. Use a pre('save') hook. Check isModified so profile updates do not rehash. Mark the field with select: false. Never log passwords.

Q6: How do you handle password resets?

Generate a random token, store its hash with a 15-min expiry, email a link with the raw token, verify the hash on reset, hash the new password, invalidate the token. Rate limit. Do not reveal if the email is registered.

Q7: What is a refresh token?

A long-lived token (7 days) used to get new short-lived access tokens (15 min). Stored in DB so it can be revoked. Solves the problem of long-lived JWTs being unrevocable if stolen.

Q8: How do you prevent CSRF?

Use sameSite 'lax' or 'strict' on cookies. Cross-site requests do not include the cookie. For sameSite 'none' (third-party embeds), use CSRF tokens (e.g., csurf middleware).

Q9: How do you prevent brute-force login?

Rate limit login (5 attempts per 15 min per IP and per email). Lock the account temporarily after too many failures. Use a slow hash (bcrypt, argon2) so each attempt is expensive.

Q10: How do you invalidate sessions on password change?

Bump a tokenVersion field on the user. The auth middleware checks that the JWT's tokenVersion matches the user's current one. After a change, old JWTs are rejected and the user must log in again.

The Takeaway

Auth interview answers: JWT sign on login, verify on each request, store in httpOnly cookie; revoke with refresh tokens; 401 vs 403; hash passwords with bcrypt in pre('save'); password reset with hashed token; refresh tokens for short access + long refresh; sameSite for CSRF; rate limit login; tokenVersion for session invalidation.