Backend, APIs & data · Mixed

Authentication and authorization: who you are and what you're allowed

In one line: Identity and authorization are two separate questions, and most breaches come from the second being checked in the interface and not the server.

Separation

Authentication answers who the user is. Authorization answers whether they're allowed to perform the action on the resource. Hiding a button in the interface isn't authorization — any request can be sent directly.

The rule: every route checks authorization on the specific resource, not just that the user is logged in.

Practical models

By roles — simple, enough for most systems. By ownership and affiliation — needed when users see only their organization's data. By detailed policy — powerful and expensive to maintain, and only when truly required.

Start simple and document the rules in one place in the code, not scattered across twenty checks.

Tokens

A short expiry for an access token, a refresh token that can be revoked, and a denylist for logout events. Keep enough on the server side to revoke access immediately — a capability needed exactly on the day there's no time to build it.

Going deeper

The most common danger is direct access to a resource by identifier: swapping a number in the address that returns another's data. Check this systematically on every route that receives an identifier, and add an automated test that tries to access across users.

Security