What is the difference between authentication and authorization?

Authentication establishes who someone is. Authorization determines what that identity is allowed to do. They are sequential: you cannot meaningfully decide permissions before you know the identity, which is why authentication comes first in every request pipeline.

In practice authentication is the narrower problem. A user presents a credential, the system verifies it, and the result is an identity attached to the request. It happens once per request, usually in shared middleware, and the outcome is binary.

Authorization is where the complexity lives, because the answer depends on the specific action and the specific resource. The same user may read a document, edit their own, and be refused on someone else. That means authorization checks cannot generally be hoisted into one place at the edge; they belong close to the operation, where both the identity and the target are known.

This is the source of the most common security bug in web applications: verifying the token carefully, then trusting an identifier from the request without checking it belongs to the authenticated user. Fetching a record by an identifier supplied in the URL and returning it, without confirming ownership, means anyone with a valid login can read anyone else data by changing a number. The authentication was perfect and the authorization was absent.

A related trap is trusting claims embedded in a token beyond their verified scope. A signed token proves the issuer asserted those claims at issue time. If a role was revoked afterwards, the token still says otherwise until it expires, so anything requiring immediate revocation needs a server-side check rather than the token alone.

Keeping the two concepts distinct in your own vocabulary helps, because a great deal of confused security design comes from treating a successful login as though it settled the question of permission.