Authentication Service System Design Interview: Draw the Line

The interviewer is not asking you to recite OAuth flows. They want to see you scope a vague prompt, separate trust zones, and defend a default under follow-up. So open by stating the boundary: what the auth service owns (issuing and verifying identity) and what callers own (trusting a verified claim). Then let every later choice — token type, session store, revocation, scaling — fall out of that line. This guide gives you a spoken structure and a defensible default for the authentication service system design interview, not a protocol catalogue.

What is the interviewer actually testing?

Three things get scored. Can you turn "design authentication" into requirements? Can you separate trust zones before you draw boxes? Can you defend a default when they push back?

Most candidates open with technology. That reads as recall, not design.

Weak opening: "I'll use OAuth with JWTs, put a Redis session store behind it, and add refresh tokens."

Stronger opening: "Before I pick a mechanism, I want to fix the boundary: the auth service issues and verifies identity; every other service consumes a verified claim and never sees a password. Then I'll choose a session model against the revocation requirement."

The second version tells the interviewer you have a reasoning spine. Everything you say next can hang off it.

Here is a 60-second opening you can say almost verbatim:

"Let me scope this first. I'll assume a consumer app with web and mobile clients, an auth service, and downstream services that need to know who the user is. The boundary I want to draw: the auth service owns credentials and issues a signed claim; downstream services trust that claim and never touch a password. I'll ask you for two numbers — how long a stale session is tolerable, and how fast a revocation must take effect — because those decide whether I use short-lived tokens or a server-side session. Then I'll walk through storage, revocation and failure."

That is roughly 30 seconds spoken. Use the rest to ask your two questions.

Step 1: Turn the prompt into requirements you can defend

Ask who the actors are before anything else:

• End user on web and mobile
• Client apps (first-party, maybe third-party)
• Internal services that need identity
• Admins who can disable accounts

Then define what "logged in" means for each. For a consumer app, it usually means: a user proves ownership of a credential, receives a claim, and can be logged out or disabled. Write five requirements and say which are assumptions.

"Five requirements: one, users sign in with email and password on web and mobile; two, sessions last up to 30 days on mobile with re-auth for sensitive actions; three, logout on one device takes effect within about a minute; four, an admin disable takes effect within seconds; five, downstream services verify identity without calling the auth service on every request. I'm assuming first-party clients only — tell me if third-party access is in scope."

Split functional from non-functional and ask for two numbers: session lifetime tolerance and revocation latency tolerance. Those two figures drive the session-model choice later. Naming them early also shows you know non-functional requirements are part of the design, not an afterthought.

Step 2: Draw the trust boundary before you draw boxes

Say the split out loud: the auth service issues and verifies identity; downstream services consume a verified claim and never see credentials. That single sentence prevents the most common muddle — treating authentication and authorization as one box.

Describe the boundary in words, not boxes on a whiteboard:

• Client holds a credential or token, never a password after login.
• Edge terminates TLS and forwards requests.
• Auth service checks credentials, issues claims, handles refresh and revocation.
• Token or session store holds what the auth service needs to verify or revoke.
• Downstream services verify the claim and act on it.

The line to say: "Everything past this line trusts a signed claim, not a password." This works because it gives the interviewer a stable reference point. When they ask "what if the token is stolen?", you answer inside the boundary rather than rebuilding the whole design.

Step 3: Pick a session model and say why

Two honest defaults: short-lived signed token plus refresh, or server-side session lookup. Compare them on what the interviewer cares about.

For the consumer-app example, choose short-lived access tokens (minutes) plus refresh, with a small deny list for logout and disable. Say the condition that would flip you: "If revocation latency had to be under a second for every request, I'd move to server-side sessions and accept the lookup cost." That sentence is the whole point of the exercise — a default plus a trigger.

Step 4: Where do credentials and secrets actually live?

Keep password storage to one paragraph. Store a slow hash with a per-user salt, never plaintext, never reversible. Say it briefly and move on — going deep here sounds like a security interview, not a system design one.

Treat key management as a boundary question: who can rotate signing keys, and what breaks during rotation? The answer is usually that old keys stay valid until their tokens expire, so rotation is a two-key overlap, not a switch.

Pre-empt one mistake: putting the token store and the credential store in the same failure domain without saying so. If both go down together, nobody can log in and nobody can be verified. Name it before the interviewer does.

Step 5: Revocation, logout and the question interviewers love

Walk through two different problems. "User clicks logout on one device" is a single-session revocation. "Admin disables an account" is a user-wide revocation. They need different mechanisms and different latency.

Tie each to the number from Step 1. If logout must take effect within a minute, a deny list checked on refresh is enough. If disable must take effect in seconds, downstream services need a fast path to check a revoked-user flag.

The follow-up you should expect: "What if the token is still valid after logout?" Answer with the trade-off, not a fix:

"For up to the token lifetime, a stolen token could still work. That's the cost of local verification. I accepted it because the requirement was a minute, not a second. If it were a second, I'd switch to server-side lookup."

That answer shows you understood the gap and priced it. See how to respond to follow-up questions by extending the reasoning rather than restarting it.

Step 6: Scale and failure — what changes at 10x

Three levers: cache verified claims at the edge, shard the session store by user id, keep the auth service stateless where possible. Each one follows from the boundary — you are scaling verification, not credentials.

Run a failure drill out loud: "If the auth service is down, existing sessions still verify locally and keep working; new logins fail. That's acceptable because the blast radius is new sign-ins, not the whole product." Saying it calmly matters more than the answer.

Add one sentence on rate limiting login attempts as a boundary concern: it protects the credential store, so it belongs to the auth service, not the edge.

A 25-minute narrated walkthrough you can rehearse

• 0–3 min: requirements and the two numbers
• 3–7 min: trust boundary in words
• 7–13 min: session model and trade-off table
• 13–18 min: storage and revocation
• 18–22 min: scale and failure
• 22–25 min: wrap-up

At each transition, say one sentence so the interviewer can follow: "That's the boundary; now the session model." Close by restating the boundary, the default, and the one thing you would validate next.

Practise out loud. If you have no study partner, record yourself and check that each transition sentence is present. Our blog has related walkthroughs, including API design and consistency models, if you want more spoken structures.

The four mistakes that sink authentication answers

• Protocol-first opening with no requirements. Fix: state the boundary first.
• Treating authentication and authorization as one box. Fix: name the split explicitly.
• Claiming "stateless" while quietly needing a revocation list. Fix: admit the deny list.
• Never naming a number for session lifetime or revocation latency. Fix: ask for both in the first three minutes.

Before you walk in

One takeaway: the boundary is the answer, and every later choice should be traceable to it. One thing to do next: rehearse the 60-second opening and the two-number question until they sound natural. If you can say those without notes, the rest of the authentication service system design interview has somewhere to stand.

Frequently asked questions

Should I bring up OAuth or SAML in the authentication service system design interview, or does that look like reciting?

Mention them only after you have stated the boundary and the session model. Naming a protocol early reads as recall; naming it as a consequence of your requirements reads as design. If the interviewer asks directly, answer briefly and return to the trade-off you were defending.

What if the interviewer pushes me toward a design I think is worse?

Say what you would trade and why, then follow their direction. "Server-side sessions give faster revocation but add a lookup per request; if that's the priority, I'd take it." You are scored on reasoning under constraint, not on winning the argument.

How much detail on password hashing is enough before it sounds like a security interview?

One or two sentences: slow hash, per-user salt, no plaintext. Then move to key management and revocation, which are boundary questions. Going deeper rarely earns points in a system design round and eats time you need for the session model.

Is it okay to say 'I would look this up' during a system design answer?

Yes, if you say what you would look up and why it does not change the design. "I'd check the exact rotation procedure, but the shape is a two-key overlap." That keeps the reasoning visible instead of pretending to certainty.

How do I practise this answer out loud without a study partner?

Record yourself against the 25-minute plan and listen for the transition sentences and the two numbers. Rehearse the 60-second opening until it is fluent. The goal is a spoken structure you can adapt, not a memorised script.

Rehearse the 60-second opening and the two-number question out loud.