Authentication and authorization are two distinct security steps: authentication verifies who a user is, and authorization determines what that verified user is permitted to do. They happen in that order (you can’t decide someone’s permissions until you know who they are) and confusing them leads to real security gaps.

The shorthand: authentication is "who are you?", authorization is "what are you allowed to do?" Both are essential, and each fails in different ways.

How they work together

A login illustrates the sequence. When a customer signs in, authentication checks their credentials or passkey to confirm identity. Once confirmed, authorization takes over: it checks what this particular user can access, their own accounts, yes; another customer’s, no; an admin function, definitely not. Authentication opens the door; authorization decides which rooms you can enter.

Where each is enforced

Authentication is typically handled at the identity layer, the identity provider, the CIAM platform, the passwordless or MFA system. Authorization can live in several places: coarse-grained roles in the application, or fine-grained, policy-based decisions evaluated per request (increasingly via dedicated authorization services using models like RBAC, ABAC, or ReBAC).

Common mistakes

Two failures recur. The first is strong authentication with weak authorization. You rigorously verify who someone is, then fail to properly restrict what they can do, so a legitimate low-privilege user reaches data they shouldn’t (a classic broken-access-control flaw). The second is treating authentication as sufficient on its own: proving identity says nothing about whether that identity should have access to a given resource.

Why the distinction matters more now

As architectures move toward zero trust and APIs multiply, authorization has become its own hard problem. It’s not enough to authenticate a user once at the perimeter; each request may need a fresh, fine-grained authorization decision based on context and risk. And with AI agents acting for users, the question shifts from "is this the user?" to "is this agent authorized to do exactly this, right now, and nothing more", which is pushing authorization toward ephemeral, tightly scoped grants.

A worked example

Consider online banking. A customer logs in with a passkey: that’s authentication, and it confirms the person is the account holder. Now they navigate the app. Viewing their own balance is authorized; attempting to view another customer’s account is not. Initiating a small transfer to a saved payee may be authorized outright; wiring a large sum to a new payee triggers a step-up (an authentication event driven by an authorization policy about risk). Same authenticated user, many different authorization decisions, each evaluated against who they are, what they’re doing, and the risk of the moment. Authentication happened once at the door; authorization is happening continuously inside.

The pitfall: broken access control

The most common and damaging authorization failure is broken access control, where an authenticated user can reach data or actions they shouldn’t. It routinely tops industry vulnerability rankings (it’s the first item on the OWASP Top 10). Classic forms include changing an ID in a URL to view someone else’s record, or calling an API endpoint that never checks whether the caller is entitled to the object they’re requesting. The lesson is that authenticating users rigorously does nothing to prevent this; authorization must be enforced on every request, server-side, against the specific resource, not assumed because the user logged in.

How authorization is modeled

Authorization decisions have to come from somewhere, and there are a few common models for expressing "who can do what":

• Role-based access control (RBAC) grants permissions by role, an "admin" can do these things, a "customer" those. Simple and widespread, but it gets unwieldy as roles multiply.
• Attribute-based access control (ABAC) decides based on attributes of the user, resource, and context (department, location, time, risk). More flexible, more complex to reason about.
• Relationship-based access control (ReBAC) decides based on relationships between entities ("can edit documents in a folder they own"), the model behind fine-grained authorization at scale.

Increasingly, authorization is pulled out of application code into a dedicated service that evaluates policies per request. That separation matters for zero trust and for APIs, where each call may need a fresh decision, and it’s where fine-grained authorization has become its own discipline rather than a few if statements scattered through the codebase.

Frequently asked questions

Which comes first, authentication or authorization?

Authentication comes first (verify identity), then authorization (determine permissions).

What are RBAC, ABAC, and ReBAC?

Three authorization models (by role, by attributes, and by relationships) for expressing what an authenticated user is allowed to do.

Can you have authorization without authentication?

No. You must establish who someone is before deciding what they can do.

What is broken access control?

A failure where authenticated users can reach resources or actions they shouldn’t, due to weak authorization.

Is MFA authentication or authorization?

MFA is authentication. It strengthens the proof of identity, not the permissions.

Why is authorization getting harder?

Zero trust and APIs require fresh, fine-grained decisions per request, and AI agents need tightly scoped, short-lived permissions rather than broad standing access.

Related: Authentication · Authorization · Fine-Grained Authorization (FGA) · Role-Based Access Control (RBAC) · Zero Trust