Authentication vs authorisation

Authentication answers a question about identity, and it is answered once at the start of a session by a password, a token, a passkey or an identity provider. Authorisation answers a question about permission, and it has to be answered again on every single request that touches something worth protecting. The two are routinely spoken about as one topic because they sit next to each other in the login flow, but they fail in completely different ways and the remediation for one does nothing for the other.

In assessment work the second is where the findings are. Authentication is largely a solved problem that most teams now delegate to a library or a provider, and a serious flaw in it is comparatively rare. Authorisation is written by hand, in application code, for every endpoint, by whoever built that endpoint that week — and it is therefore where an identifier in a URL turns out to be trusted, or where an interface hides an action the API still happily performs for anybody who calls it directly.

Where the boundary is usually crossed

• Checks performed in the interface rather than the server. Hiding a button prevents nothing; the request behind it is still there and still accepted.
• Object-level checks that verify the caller is logged in but never that this particular record belongs to them, which is the defect that reads other customers’ data.
• Function-level gaps, where an administrative route was protected by not being linked anywhere and is reachable by anyone who guesses or reads the bundle.
• Trusting a claim inside a token without verifying its signature and issuer, which turns a role field into something the caller can simply write for themselves.

Authentication happens once per session; authorisation has to happen on every request, and the flaws worth finding almost always sit on the second question rather than the first.