Design a login and session service

If the user table leaks, an attacker with a graphics card can test billions of fast hashes a second. Store the output of a slow, salted password hash: Argon2id, scrypt or bcrypt. They are built to cost real time, and in some cases real memory, on purpose. Tune the cost so one hash takes about 100 ms on your login servers, and raise it as hardware gets faster.

A salt is a random value, unique to each account, stored beside the hash and fed into it. Two people with the same password then get different hashes, and an attacker cannot use one precomputed table against everyone. The stored string also records the algorithm and its cost settings, so you can raise the cost later: on the next successful login, hash again with the new settings.

Compare the result with a constant-time comparison, so the response time does not reveal how much of the hash matched. When the email has no account, do the same work by hashing against a dummy value, and give one message for both cases, such as 'Email or password is wrong'. Otherwise the login form becomes a way to find out who has an account.

Throttling. The slow hash costs the attacker for each guess, but it also costs you 100 ms of CPU for each attempt. In our estimate an attack of 1,000 attempts a second would keep 100 cores busy. So count attempts before hashing, in the attempt counters:

• Per account: after 5 failures in 15 minutes, add a growing delay or ask for a challenge. This stops guessing at one account.
• Per IP address and per device: a looser limit, since many people share one address. This slows an attack that tries one common password on many accounts, known as password spraying.
• Check new passwords against lists of leaked ones at sign-up, and rate-limit sign-up and password reset too.

A hard lockout after a few failures is simple, but it lets anyone lock a victim out by typing wrong passwords on purpose. Prefer delays and challenges, and let a login from a device the person has used before skip the delay. An optional second factor, such as a time-based code from an authenticator app, makes a stolen password alone useless. Plan the recovery path early, with backup codes, because people lose phones.

An opaque session ID is a random string. The server looks it up in a fast store on every request. It is simple, and revoking it is instant, but every API call costs a store read. At 50,000 requests a second that is a heavy, always-on dependency.

A signed access token carries the user ID, an expiry time and a few claims, with a signature made by the Auth service's private key. Any gateway can verify it with the public key and no lookup. The price is that you cannot take it back before it expires, so keep it short, 15 minutes, and pair it with a long-lived refresh token.

The refresh token is a long random string that only the client holds. The server stores its hash, with the user, the device and an expiry of 30 days. When the access token runs out, the client sends the refresh token and gets a new pair. This is the only step that reads the session store, about 2,300 requests a second in our estimate and not 50,000.

Rotation and reuse detection. Each refresh token works once. On a refresh, the server marks the old token as used and issues a new one in the same session family, in a single conditional write. If a used token turns up again, two parties hold the same token: the owner and a thief. The server cannot tell which one is calling, so it revokes the whole family and the person logs in again. A grace window of a few seconds for the old token tolerates a repeated request from a flaky network.

Where tokens live. On the web, put the refresh token in a cookie with three flags. HttpOnly hides it from page scripts, so an injected script cannot read it. Secure sends it only over HTTPS. SameSite=Lax or Strict stops other sites from making the browser send it, which blunts forged requests. Limit the cookie's path to the refresh endpoint, so it does not travel with every call, and keep the access token in memory rather than in local storage. On mobile, use the system's secure storage.

Give each signing key an ID in the token header. Then you can rotate keys on a schedule and keep publishing the old public key until the last token signed with it has expired.

The devices screen reads these rows, and 'log out' on one device sets the flag on one row. Key the table by user ID so both reads stay on one shard.

Log out everywhere sets the flag on all of the person's rows and raises a token version on the account by one, in one transaction. A password change or reset does the same. Every refresh checks that its session row is not revoked and that the version matches the account, so no old refresh token survives.

That leaves the access-token window. A token issued 2 minutes ago stays valid for 13 more. Choose what is acceptable:

• Accept up to 15 minutes for ordinary reads. It costs nothing and is the usual choice.
• For sensitive actions, such as changing an email address or moving money, check the session row or token version on the server before acting. It adds one read to a rare request.
• For an emergency, such as an account takeover, keep a small denylist of user or session IDs revoked in the last 15 minutes. Each gateway holds it in memory, fed by an event stream. Entries can expire after 15 minutes, because by then the tokens have expired anyway, so the list stays tiny.

A shorter access token shrinks the window but raises the refresh load. At 5 minutes the load triples, to about 6,700 a second (2M ÷ 300 s). At 1 hour the window is too wide for most products.

Tell people what happened. Send an email on a login from a new device and on log out everywhere, and show the last-active time on each device so they can spot one they do not know. Delete session rows that have been unused for 30 days, with a TTL, so the table stays small.