Authentication & Authorization interview questions
Authentication & Authorization questions a Backend developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A partner integration asks for our users’ passwords so it can read their calendar. What do you offer instead, and what problem does OAuth solve?
The strongest answer: OAuth 2.0 delegated authorisation: the user signs in with us, approves a limited scope, and the partner receives a token for that scope which we can expire or revoke — the password never leaves us
Why it works: Exactly — scope, expiry and revocation are the three things a shared password can never give you.
- Delegate access, never the password.
- The user approves a limited scope.
- Tokens expire and can be revoked.
- Never accept another site’s passwords.
The interviewer asks: “JWT access token versus a server session cookie — how do you choose?” Strongest answer?
The strongest answer: Sessions (HttpOnly Secure cookie, server-side revocation) are the default for a browser app I own. JWTs fit APIs and services where I need stateless verification — short-lived access, a revocation story for refresh, never secrets in the payload.
Why it works: Exactly. Browsers + cookies + rotation is still the safest first-party web setup. JWTs are a tool for distributed APIs, not a personality.
- Browser apps: HttpOnly session cookies first.
- JWTs: short-lived, for APIs that must verify without a lookup.
- Plan revocation either way.
- Never put secrets or hashes in a JWT.
Handlers across the service check whether the caller’s role is “admin” or “manager”. A new “support” role now needs to refund an order.
What do you change?
The strongest answer: Check a permission such as order.refund rather than a role name, map roles to permissions in one place, and let the new role be a configuration change instead of a diff across every handler
Why it works: Exactly — roles are how you grant permissions; permissions are what you check. One mapping, no role names scattered through handlers.
- Check permissions, not role names.
- Map roles to permissions once.
- A new role becomes configuration.
- Never authorise in the UI.
Your login flow returns an ID token and an access token. What is each one for, and which does your API validate?
The strongest answer: The ID token tells the client who signed in and is meant for the client; the access token is the credential for calling the API, so the API validates that one — signature, issuer, audience and expiry
Why it works: Right — and naming the checks matters: issuer, audience, expiry and signature, not just “it decoded”.
- ID token: who signed in.
- Access token: the API credential.
- Check signature, issuer, audience, expiry.
- Never trust an id from the client.
The interviewer asks: “What belongs in a JWT payload?” Strongest answer?
The strongest answer: Non-secret claims you can afford to be visible: subject, expiry, issuer, maybe roles. Anyone who holds the token can read it — it's signed, not encrypted, unless I explicitly encrypt.
Why it works: Exactly. Base64 is not confidentiality. Sign for integrity; keep the payload boring and short-lived; put sensitive data behind an API.
- JWTs are readable; don't put secrets in them.
- Subject, exp, issuer — keep it small.
- Short-lived access tokens.
- Never bootstrap secrets from a JWT.
The interviewer asks: “How do you store a session on the web?” Strongest answer?
The strongest answer: A Secure, HttpOnly, SameSite cookie (Strict or Lax as the product allows). JavaScript must not read it. I don't put the session token in localStorage.
Why it works: Exactly. XSS shouldn't be able to steal the session. Secure + HttpOnly + SameSite is the 2026 browser default for first-party sessions.
- Session = Secure HttpOnly SameSite cookie.
- Not localStorage for browser sessions.
- JS doesn't need to read the token.
- No secrets in URLs.
The product wants MFA added to the existing username-and-password login, and you own the backend design.
What does the flow look like on the server?
The strongest answer: The password check issues no session — only a short-lived, single-purpose challenge token; the second factor is verified against that, rate limited and replay-protected, and only then is the real session issued
Why it works: Exactly — the intermediate credential is the design. It must not be a session, must expire in minutes, and must be rate limited.
- One factor buys a challenge, not a session.
- Short-lived, single-use challenge token.
- Rate limit and replay-protect the code.
- Recovery codes single-use and audited.
Support asks how quickly we can cut off a session after an account is reported compromised. The API accepts self-contained JWTs with an eight-hour expiry.
What is your answer?
The strongest answer: Honestly, up to eight hours — nothing is checked after issue; so shorten access tokens to minutes, rotate refresh tokens through a store we can invalidate, and keep a denylist of token ids for incidents
Why it works: Exactly — the honest answer first, then the design: short access tokens, rotating refresh tokens you can invalidate, and a denylist for the bad day.
- A self-contained token lives until it expires.
- Keep access tokens minutes long.
- Rotate refresh tokens you can invalidate.
- Denylist by token id for incidents.