Design an Authentication System: Passwords, Sessions, JWT, Refresh Tokens and MFA

One login, from password to tokens

Asha opens the app on a new phone and logs in with her email, her password and the code from her authenticator app. This is a good example to walk through in an interview.

1. 1

   Front door

   The request reaches the API gateway over HTTPS. The gateway counts requests from this IP address and for this email address, and lets it through because both are under their limits.

2. 2

   Find the user

   The auth service looks up Asha's row by email. If no row existed, it would still run a dummy hash and return the same error, so the timing and the message do not reveal which emails have accounts.

3. 3

   Check the password

   A hashing worker runs Argon2id on the typed password with Asha's stored salt and settings, and compares the result with the stored hash using a constant-time compare. It matches.

4. 4

   Second factor

   Asha has MFA turned on, so the service asks for a code. Her app shows a 6-digit code for the current 30-second window. The service accepts it and marks that code as used, so it cannot be replayed.

5. 5

   Issue tokens

   The service signs a 15-minute access token with her user id and a key id. It also creates a refresh token of 256 random bits. Only a hash of it is stored, with this phone's device id and a new family id.

6. 6

   Use the app

   Each API call carries the access token. The orders service checks the signature with the cached public key and the expiry time, then reads Asha's user id. No database call is needed.

7. 7

   Refresh and record

   After 15 minutes the app sends the refresh token. The service marks it used, issues a new pair, and writes a 'new device login' event, which also sends Asha an email so she would notice a login that was not hers.

These are the conversations the interviewer is steering you toward. Practice each one until you can talk through it without notes.

Storing passwords: slow on purpose

The first rule: never store the password. Store a hash, the output of a one-way function, so that a stolen database does not show anyone's password. The second rule surprises people: the hash must be slow. A normal hash such as SHA-256 is designed to be fast. That is good for checking files and bad here. An attacker with a stolen table can try billions of guesses a second on graphics cards. A password hash is built to be slow and to need memory, so each guess costs real work. OWASP's Password Storage Cheat Sheet recommends Argon2id with at least 19 MiB of memory, 2 iterations and 1 degree of parallelism. For older systems it accepts bcrypt with a work factor of 10 or more, and notes that most bcrypt versions read only the first 72 bytes of the password. If you must use PBKDF2, it asks for 600,000 iterations with HMAC-SHA256. Each user gets a random salt, stored with the hash, so two users with the same password get different hashes and an attacker cannot crack everyone at once. Modern hash formats store the algorithm, the settings and the salt inside one string, so you can raise the cost later. When a user logs in successfully, you have their real password for a moment. Re-hash it with the new settings and save it. Now the cost. We measured one Argon2id hash at the OWASP minimum at a median of 95 ms on one laptop core. At 463 logins a second that is 44 busy cores, so put hashing in its own pool that can grow, and rate limit login before the hash, not after it. Finally, check new passwords before you store them. NIST SP 800-63B (its 2025 revision) gives clear rules. A password needs at least 15 characters when it is the only factor, and at least 8 when it is part of MFA. Do not force mixes of character types, and do not force regular password changes. Reject passwords found on a list of common or leaked ones. A slow hash cannot save a password that is already on the attacker's list.

Sessions or tokens: how the server remembers you

After login, the client needs something to show on each request. There are two main choices. A server session: the server creates a long random id, stores the details (user, device, expiry) in a session store, and sends the id in a cookie. Each request looks up the id. OWASP's Session Management Cheat Sheet asks for at least 64 bits of entropy in the id. The cookie needs three flags. Secure means it is sent only over HTTPS. HttpOnly means page scripts cannot read it. SameSite limits when other sites can cause it to be sent. The server also gives a new session id right after login, so an attacker cannot plant an id before the user logs in. Logout is one delete, and it works at once. The cost is a store lookup on every request. A signed token, usually a JWT: the server puts the user id, an expiry time and a key id into a small JSON document and signs it with a private key. Any service can check the signature with the public key, in memory, with no lookup. That is why it scales well across many services: in our example it saves 46,000 store reads a second. The cost is that you cannot take a token back once it is issued; it stays valid until it expires. So the common design mixes both. Short-lived access tokens (about 15 minutes) that services check by signature, plus a refresh token that lives in the token store and can be revoked. For a browser-only app with one backend, plain server sessions in an HttpOnly cookie are often the simpler and safer choice. Say which one you pick and why.

Access tokens, refresh tokens and rotation

The access token is short-lived because it travels everywhere and cannot be recalled. The refresh token lives longer, days or weeks, but it is only ever sent to the auth service. When the access token expires, the app sends the refresh token and gets a new access token. Here is the problem: if a refresh token is stolen, for example from a phone backup or a log file, the thief can make new access tokens for weeks. The OAuth 2.0 security best practice, RFC 9700 (January 2025), has a rule for this. Public clients are apps that cannot keep a secret, such as mobile and browser apps. Their refresh tokens must be either bound to the client's own key (sender-constrained) or rotated. Rotation means each refresh token works once. Every refresh returns a new refresh token and marks the old one used, but the server remembers the link between them. If an old, used token ever comes back, either the real app or a thief is replaying it. The server cannot tell which, so RFC 9700 says it revokes the active refresh token, and the real user has to log in again. In practice, give every token from one login a family id, and revoke the whole family. Store only a hash of each token, the same way you store passwords, so a leak of the token table does not hand out working tokens. One more detail: mobile apps on bad networks sometimes send the same refresh twice. Many teams allow a grace period of a few seconds in which the just-replaced token still returns the same new pair, so a flaky network does not log people out. The listing below shows rotation and reuse detection in a few lines.

import hashlib, secrets

store = {}  # sha256(token) -> {"user", "family", "used"}; only hashes are kept

def h(token):
    return hashlib.sha256(token.encode()).hexdigest()

def issue(user, family=None):
    token = secrets.token_urlsafe(32)          # 256 random bits
    family = family or secrets.token_hex(4)    # one family per login on one device
    store[h(token)] = {"user": user, "family": family, "used": False}
    return token

def refresh(token):
    row = store.get(h(token))
    if row is None:
        return "rejected: unknown token"
    if row["used"]:                            # an old token came back: someone copied it
        for r in store.values():
            if r["family"] == row["family"]:
                r["used"] = True               # kill the whole family, every device copy
        return "REUSE DETECTED: family revoked, user must log in again"
    row["used"] = True                         # rotation: each token works once
    return issue(row["user"], row["family"])

t1 = issue("asha")
t2 = refresh(t1)                    # the app refreshes: t1 is now spent
print("app refresh ok:", t2 != t1)
print("thief replays t1:", refresh(t1))
print("app tries t2:", refresh(t2))

Multi-factor authentication: codes, SMS and passkeys

A password can be guessed, reused from another site or typed into a fake page. A second factor means a stolen password alone is not enough. There are three common kinds. An authenticator app uses TOTP (time-based one-time password, RFC 6238). At setup, the server and the app share a secret, usually through a QR code. Every 30 seconds, both sides compute a 6-digit code from the secret and the current time, so the app works with no network. RFC 6238 recommends a 30-second step and allowing at most one step of network delay, so the server accepts the current code and the one before it. Remember the last step that was used, so one code cannot be used twice, and encrypt the shared secret at rest, because anyone who reads it can make codes. An SMS or email code is a random 6-digit code the server generates, stores as a hash with a short expiry, and sends through a provider. It is easy for users, but SMS can be intercepted or moved to an attacker's SIM card, and it costs money per message, so limit codes per phone number and per hour. In both cases, limit wrong tries per code: with 5 tries the attacker's chance is 1 in 200,000; with 100 it would be 1 in 10,000. A passkey (WebAuthn) is the strongest. The device creates a key pair for your site; the private key never leaves the device and the server stores only the public key. At login the server sends a random challenge, the device signs it after a fingerprint or PIN, and the server checks the signature. The browser binds the key to your site's real domain, so a fake look-alike site cannot use it, which is why passkeys resist phishing. Offer recovery codes too, because people lose phones.

Stopping guessing and leaked-password attacks

Two attacks hit every login page. Brute force guesses many passwords for one account. Credential stuffing tries email and password pairs leaked from other websites, one try per account across millions of accounts, so a per-account limit alone does not see it. Use several layers. Rate limit at the gateway per IP address, per account and per device, with a token bucket in a fast shared store. Slow down repeated failures on one account with growing delays instead of a hard lock, because a hard lock lets anyone lock out any user just by typing wrong passwords. NIST SP 800-63B sets an upper bound of 100 consecutive failed attempts on one account before that authenticator is disabled, and says a lower limit is allowed. Watch the whole system for stuffing: a sudden rise in failed logins across many accounts, many accounts tried from one IP range, or many logins with known breached passwords. When the risk engine sees it, ask for a second factor or a challenge instead of blocking everyone. Return the same message and take about the same time for 'wrong password' and 'no such account', so attackers cannot use the login form to find which emails have accounts. And rate limit before the hash: the slow hash costs you about 95 ms of CPU each time, so an attacker who can make you hash without limits can take your login down.

Password reset and logging out everywhere

Password reset is a second login path, so it must be as strong as the first. OWASP's Forgot Password Cheat Sheet gives the rules. Show the same message whether or not the email has an account ('if this address is registered, we have sent a link'), and keep the response time the same. Make the reset token random from a secure generator and long enough that it cannot be guessed, store only its hash, make it work once, and let it expire after a short time. After the reset, end the user's other sessions or ask the user whether to end them. In our design, that means revoking every refresh token family for the user and deleting their server sessions. Access tokens that are already out will still work until they expire, which is the honest cost of stateless tokens: with a 15-minute lifetime, the window is at most 15 minutes. If that is too long for a bank or a payment app, make access tokens shorter. Or keep a small deny list of revoked token ids that services check, or a per-user 'tokens issued before this time are invalid' value. The same tools power the 'log out of all devices' button and the response to a reported account takeover.

Log in with Google: OAuth 2.0 and OpenID Connect

Many users would rather not make another password. Social login lets an identity provider such as Google prove who they are. The protocol is OpenID Connect (OIDC), a login layer on top of OAuth 2.0. Your app sends the user to the provider's login page. After the user agrees, the provider sends back a short code. Your server exchanges the code for an ID token: a signed JWT that says who the user is and which provider vouched for it. Your server checks the signature with the provider's public keys, and checks that the token is for your app and has not expired. Then it finds or creates the local user linked to that provider account. RFC 9700 says public clients, such as mobile and single-page apps, must use PKCE (Proof Key for Code Exchange). The app makes a random secret and sends only its hash at the start. It shows the secret when it exchanges the code, so a stolen code is useless to anyone else. It also says not to use the old implicit flow that returned tokens in the browser address bar. After social login, issue your own access and refresh tokens as usual; do not pass the provider's tokens around your own services. Be careful when linking accounts: only link a Google account to an existing local account by email if the provider says the email is verified, or an attacker could claim someone else's account.

How an authentication system actually does it

The rules on this page come from the documents security teams actually follow. OWASP's cheat sheets set the password hash settings: Argon2id at 19 MiB, 2 passes and 1 lane, or bcrypt at work factor 10 or more. They set the session cookie rules: 64 bits of entropy, the Secure, HttpOnly and SameSite flags, and a new id after login. They also set the password reset rules: the same message for every email, and single-use expiring tokens. NIST SP 800-63B, in its 2025 revision, sets password length, bans forced complexity and forced regular changes, asks for a check against leaked passwords and caps failed attempts at 100. RFC 6238 defines the 30-second codes in authenticator apps. RFC 9700, the OAuth 2.0 security best practice published in January 2025, requires PKCE for public clients and rotation or binding for their refresh tokens. The hash time and every capacity number on this page are our own arithmetic and measurement, shown in full, not figures from any company.

Frequently asked questions