Authentication and access control

Authentication is figuring out who someone is. Authorization, or access control, is deciding what they're allowed to do. You need both: knowing a request is from Alice doesn't mean she's allowed to see Bob's account.

A user proves who they are once, with a password plus a second factor, or by signing in through another provider. The login service gives them a token that says who they are and when it expires. They send that token with every request, so they don't have to log in again.

An API gateway can check the token before a request reaches any service, so each service doesn't have to. Each service still decides what that user is allowed to do with its own data.

Self-contained tokens can be checked without calling the login service, which is fast, but they're hard to revoke before they expire. Keeping sessions on the server is easy to revoke but needs a lookup on every request. A common middle ground is short-lived tokens that get refreshed.

• Keep 'who are you' and 'what can you do' separate when you talk about it.
• Say where tokens get checked, and what happens when one expires.
• For sensitive data, mention encryption, audit logs and rate limiting logins.

Logging in to a web app

A user logs in to a web app that's backed by several services behind an API gateway. You want logins to be fast to check, and you want to be able to log someone out everywhere.

1. The user sends their email and password over HTTPS. The login service compares the password against a slow, salted hash, like bcrypt or Argon2, never the plain password.
2. If they have two-factor turned on, it asks for the code before going further.
3. It issues two tokens: a short-lived access token, say 15 minutes, signed so anyone with the public key can verify it, and a long-lived refresh token stored in the database.
4. The access token goes with every request. The gateway checks the signature and expiry without calling the login service, so it's cheap.
5. The orders service gets a request for order 456 from user 12. It checks that order 456 belongs to user 12. The token only says who they are, not what they own.
6. When the access token expires, the app sends the refresh token to get a new one. The login service checks the refresh token in its database first.
7. 'Log out everywhere' deletes the user's refresh tokens. Within 15 minutes, every session is gone, because nothing can get a new access token.

Things interviewers tend to ask once you've brought this up.

Where should a browser store the token?

An HttpOnly, Secure cookie is the usual answer, since JavaScript can't read it, which protects it from cross-site scripting. Then you need protection against cross-site request forgery, like SameSite cookies.

What's the difference between OAuth and OpenID Connect?

OAuth is about letting an app act on your behalf, like reading your calendar. OpenID Connect adds a standard way to say who you are on top of it, which is what 'Sign in with Google' uses.

How do services talk to each other securely?

With their own credentials, like service tokens or mutual TLS, so a service can prove who it is. Pass the user's identity along when a service acts for a user.

How would you stop password guessing?

Rate limit by account and by IP, slow down after failures, and require two-factor for sensitive accounts. Don't lock accounts permanently, or attackers can lock out real users.

• Treating a valid token as permission to do anything.
• Storing passwords with a fast hash like SHA-256, or worse, in plain text.
• Long-lived access tokens with no way to revoke them.
• Putting sensitive data in a token. It's signed, not encrypted, so anyone can read it.
• Error messages that reveal whether an email has an account.

• Rate limitingStop too much traffic with token buckets and sliding windows.
• Caching strategiesMake reads faster, and figure out what to do when data changes.
• Consistency and the CAP theoremWhat happens when copies of your data can't agree.