Authentication & Authorization Interview Questions and Answers

Authentication (authn) establishes who the caller is: verifying a password, a session cookie, a token or a certificate. Authorization (authz) decides what that identified caller is allowed to do.

authn: "You are user 42."      -> 401 if missing
authz: "User 42 may delete this order." -> 403 if denied

Authentication normally happens once per session or token, while authorization is evaluated per request or per resource. A common bug is stopping at authentication and forgetting authorization, allowing any logged-in user to access another user's data (an insecure direct object reference). Best practice is to enforce authorization close to the data, for example scoping every query by the caller's tenant or user id, rather than trusting an id supplied by the client. Keep identity data in the token or session and derive permissions from a central policy or role service.

Session-based authentication stores session state on the server and gives the client an opaque session identifier in a cookie. It is easy to revoke (delete the session), supports immediate logout of all devices, and keeps sensitive data server-side. It requires shared session storage such as Redis when horizontally scaled, and can be vulnerable to CSRF if cookies are used.

Token-based authentication, typically JWT, is stateless: the server verifies a signed token without a lookup. This scales well and works across services and mobile clients, and tokens in an Authorization header are not sent automatically, reducing CSRF risk. The trade-off is revocation: a valid JWT stays valid until it expires, so you need short lifetimes, refresh tokens and denylists.

Authorization: Bearer <jwt>
Cookie: session=opaque-id; HttpOnly; Secure; SameSite=Lax

Many systems combine both: short-lived access tokens for APIs and a server-side refresh or session record for control.

A JSON Web Token is a compact, URL-safe token with three base64url parts separated by dots: header, payload and signature.

eyJhbGciOiJIUzI1NiJ9 . eyJzdWIiOiI0MiJ9 . signature
header                 payload              signature

The header names the signing algorithm and type. The payload holds claims such as iss (issuer), sub (subject), aud (audience), exp (expiry), iat, nbf and custom claims like roles. The signature protects integrity: anyone can decode the payload, so never put secrets in it.

Key points: a JWT is signed, not encrypted (JWE is the encrypted variant). Verification must check the signature with the expected algorithm and validate exp, nbf, iss and aud. Because the server trusts the token without a lookup, revocation requires short lifetimes plus a denylist or a version claim. Never trust a payload you have not verified.