Authentication & Authorization Basics

Every system that has users eventually has to answer two questions about each request: who is making it, and are they allowed to do it? They sound like one question, and mixing them up is behind a surprising number of security bugs. This chapter separates them, then looks at the common ways a system answers each.

At a hotel's front desk you show your passport and the clerk confirms you are the person who booked. You are given a key card. That card opens your room and the gym, but not other guests' rooms. Staff cards open more doors, and the manager's opens nearly all of them. Two separate things happened: the clerk checked who you are, and the card then decided where you may go.

• -Showing the passport is authentication (often shortened to authn): proving who you are.
• -The key card opening some doors and not others is authorization (authz): deciding what you are allowed to do.
• -Authorization only makes sense once identity is established, because you cannot decide what someone may do until you know who they are.

• -API key: a static secret that the client sends with every request. It is simple, but it is hard to limit finely and awkward to rotate, and anyone who holds it is you. Think of a house key.
• -Session cookie: the server keeps the session in a shared store and hands the client an opaque reference to it, like the numbered ticket from the stateless chapter. Easy to revoke, but it needs a lookup on each request.
• -JWT (JSON Web Token): a signed, self-contained token that carries the user's identity. No lookup is needed to check it, at the cost of harder revocation. Think of a ticket with your name and seat printed on it and a seal the guard can check.
• -OAuth2: a protocol for delegated access, which is how Sign in with Google works. Think of a valet key: it lets the valet drive your car without giving them your master key, and it cannot open the boot.

A JWT has three parts separated by dots: a header, a payload and a signature. The payload is just a small piece of JSON describing the user and when the token expires:

The signature is calculated from the header and payload using a secret key that only the server holds. To check a token, the server recalculates the signature and compares. If a user edits the payload to say admin, the signature no longer matches, and the token is rejected. Note that the payload is readable by anyone, so never put secrets in it. Signing proves the token has not been changed; it does not hide what is inside.

The trade-off is revocation. Because no lookup is made, a leaked token keeps working until it expires. The usual compromise is a short-lived access token (for example 15 minutes) paired with a longer-lived refresh token that the server can cancel.

Once you know who someone is, Role-Based Access Control (RBAC) gives them one or more roles, such as viewer, editor or admin, and each role carries a set of permissions. A viewer can read; an editor can read and write; an admin can read, write, delete and manage users. Checking authorization becomes a lookup of whether this role permits this action, instead of hard-coding rules for each individual user, which stops working beyond a handful of people.

The diagram shows where the first check happens: the gateway validates the token locally, with no call to an auth service on every request.

• -At the gateway: is the token valid and unexpired, and is this role allowed on this route at all? Coarse checks, done once for every service.
• -In the service: does this particular user own this particular order? Fine-grained checks need data only the service has.
• -Never in the client: hiding a Delete button is a convenience, not security, because anyone can send the request by hand.

• -Trusting what the client says about itself, such as a role or user id in a request body, instead of reading it from the verified token.
• -Checking authentication but forgetting authorization: a logged-in user who can fetch anyone's order by changing the id in the URL.
• -Long-lived tokens with no way to revoke them.
• -Putting secrets in a JWT payload, which is readable by anyone.