Authentication vs. Authorisation: What's the Difference?
In Brief
Authentication establishes confidence in an identity claim. Authorisation decides whether a requester, including an anonymous visitor, may perform a particular action on a resource. A valid login alone doesn't grant access to every record or operation.
A person can log in successfully and still be refused access to an invoice. That isn't necessarily a broken login. The system may know which account is making the request and correctly decide that the invoice belongs to somebody else.
An Authenticated Account isn't a Universal Permission Slip
In a web application, authentication usually establishes that a requester can prove control of credentials linked to an account. That doesn't necessarily establish their legal identity or prove that the person using those credentials is trustworthy.
A session lets the application associate later requests with that authentication event, but it still needs a separate decision about what each request may do. An account that can read its own invoices doesn't automatically gain access to every invoice on the server.
State the rule in terms of the resource and action: an account may read invoices belonging to its organisation. That's more useful than saying the invoices are "behind login", and gives implementation and tests something specific to enforce.
It also makes the failure easier to describe. An expired session and a valid session without permission need different investigation. Both might look like "I can't get in" to the user, but treating them as one technical problem can send the team towards the wrong fix.
Authorisation Can Apply Without Login
Public pages show that authorisation doesn't always follow authentication. A service can permit anonymous visitors to read published articles whilst reserving editing for a smaller group. The policy still decides which requesters may perform which actions, even when no personal account is involved.
Machine‑to‑machine requests make the same point from another direction. The subject of an access decision might be an application or service account rather than a person sitting at a login form.
A Role is an Input to a Decision
Roles such as "editor" and "administrator" are useful permission groups, but they don't describe every access rule. An editor may be allowed to change content in one publication but not another. Resource ownership, organisation membership, workflow state, and the requested action can all matter.
Make the scope explicit: "editors can edit" leaves too much unanswered. Reading a draft and publishing it are different actions, even when they concern the same content. If someone loses organisation membership or has a capability withdrawn, decide what their next request should allow; a decision made at login cannot be assumed to last indefinitely.
The Interface Can Explain a Rule; It Can't Enforce It Alone
Hiding an action can make the interface clearer, but it doesn't stop someone requesting the underlying operation directly. Enforce permission in the trusted part of the system before returning protected data or performing the action. A disabled "Delete" button and an authorised delete operation need separate checks; trace the request to the point where the service makes that decision.
Where Oauth and Openid Connect Fit
OAuth 2.0 is an authorisation framework. RFC 6749 describes obtaining limited access to an HTTP service, including delegated access on behalf of a resource owner. "OAuth" on its own doesn't explain how an application authenticates its users.
OpenID Connect adds an identity layer on top of OAuth 2.0, allowing a client to verify information about the end user's authentication. The names are easy to mix up because the protocols work together, but they answer different questions.
Even when an identity provider authenticates the user successfully, the application still needs its own appropriate access decisions. "This is account 42" doesn't answer whether account 42 may publish this article or approve this expense.
For one framework integration, see the NextAuth.js authentication article. A library can handle protocol and session machinery; the product still has to define and enforce its resource permissions.
I use British English, so the spelling here is "authorisation". Specifications and API names may use "authorization"; preserve those literal names when writing code or referring to an exact field.