Authorization is the process that determines what an already-verified identity is allowed to do or access. It runs after authentication confirms who someone is, and it governs every action that follows, from viewing an account to approving a transaction to letting an AI agent act on a customer's behalf.
What authorization means in practice
Authorization answers one question: now that we know who (or what) this is, what is it allowed to do? It's a decision, not a login screen. Every time a customer opens an account statement, a partner pulls inventory data through an API, or an AI agent books an appointment on someone's behalf, an authorization check runs in the background to confirm that action is permitted. Get authorization wrong and the consequences are concrete: customers see data they shouldn't, partners overreach into systems outside their contract, and audits turn up access nobody can explain. Authorization is a core function inside any CIAM system, sitting right alongside authentication, consent, and fraud prevention as one of the pieces that has to work together.
How authorization works
An authorization decision needs three inputs: who is asking, what they're asking to do, and the context around the request. A policy decision point evaluates those inputs against a set of rules and returns an allow or deny. That decision then gets enforced at the resource itself, the API, application, or data store that's actually being protected, because a decision that's made but never enforced isn't worth anything.
Different models express those rules differently:
- Role-based access control (RBAC). Access is tied to a role, such as "account owner" or "supplier admin." Simple to reason about, but roles multiply fast in large organizations and get stale as responsibilities shift.
- Attribute-based access control (ABAC). Access is evaluated against attributes of the user, the resource, and the environment, like account tier, data sensitivity, or time of day. More flexible than RBAC, but harder to audit if attributes aren't well governed.
- Delegated authorization. One party grants another limited, scoped permission to act on its behalf, without handing over credentials. This is the model behind standards like OAuth 2.0 (RFC 6749), and it's the same pattern that governs AI agents acting for a customer or a business.
Modern approaches increasingly separate the decision from the enforcement, so a policy decision point can be called consistently by any application or API, an approach reflected in emerging standards like the OpenID AuthZEN Authorization API. That separation is also what makes identity orchestration possible: policies get defined once and applied consistently across every channel, instead of being rebuilt inside each app.
Authorization vs. authentication
These two get conflated constantly, and the mix-up causes real problems. Authentication verifies identity. Authorization determines what that verified identity can do. A sign-in flow needs both, in order: first prove who you are, then decide what you're allowed to touch. A password, a passkey, or an MFA prompt is authentication. The rule that says a customer can view their own order history but not someone else's is authorization.
| Authentication | Authorization | |
|---|---|---|
| Question answered | Who is this? | What is this identity allowed to do? |
| When it runs | At the start of a session | Continuously, on every protected action |
| Common artifact | Credential, passkey, MFA factor | Role, scope, policy, permission |
| Common misuse | Treated as sufficient on its own | Skipped or hardcoded, assuming authentication settles it |
Treating a successful login as proof that every subsequent action is fine is the mistake to avoid. Authentication happens once per session. Authorization has to be checked every time, because what an identity is allowed to do can change mid-session, and because a valid login says nothing about whether this specific request should be permitted.
Authorization vs. access control
Authorization is the decision. Access control is the broader system that carries that decision out, including the policies, the enforcement points, the audit trail, and the administration around all of it. Authorization is one function inside an access control system, alongside identity verification, session management, and logging. When people say "access control," they usually mean the whole apparatus. When they say "authorization," they mean the specific yes-or-no answer at the center of it.
Why authorization matters for customer, partner, and AI agent identities
Authorization used to be mostly about employees and internal systems. That's no longer the whole picture. Customers need boundaries around their own accounts. Partners need access scoped tightly to what their contract actually covers, not a blanket door into shared systems. And a growing category of non-human identity, AI agents acting on behalf of a customer or a business, needs the same rigor: verified identity, defined permissions, and a record of what it did and under what authority.
Delegated authorization is what makes agent access safe. An agent shouldn't hold a customer's credentials. It should hold a scoped grant, tied to consent, that can be reviewed and revoked without disrupting the human's account. Agentic identity is built on exactly this principle: govern the agent the same way you'd govern a person, with authorization and consent management as the controls that keep automation accountable instead of open-ended.
What to look for in a modern authorization approach
A few things separate a workable authorization model from one that becomes a liability as the business grows.
- Adaptive, risk-based decisions. Static roles alone don't account for context. A modern approach layers adaptive access controls on top, so a request from an unusual location or device can trigger a step-up check even when the role would otherwise allow it.
- Low-code policy configuration. Rules that live in code are slow to change and easy to get wrong. Policies that business and security teams can configure directly shorten the time between "we need to change this" and it actually being changed.
- Consistency across channels and identity types. The same policy should govern a customer on web, on mobile, and through an API, and it should extend to partners and AI agents without a separate system for each.
- Auditability. Every authorization decision should be traceable: who or what asked, what was decided, and why. This is what turns access control into evidence an auditor can actually use.
- Support for non-human identities from the start. Bolting agent governance onto a system designed only for humans tends to leave gaps. Authorization built to handle scoped, delegated grants for agents from day one avoids that retrofit.
For a broader view of where authorization fits among other identity capabilities, see the 15 essential CIAM capabilities, and for how CIAM and IAM relate more generally, see what's the difference between CIAM and IAM.
Frequently asked questions
Who checks authorization, the app or the identity system?
Typically the resource being accessed (an API or application) checks the scopes or claims in the token it receives; the identity system's job is to issue that token accurately.
Can authorization change without re-authenticating?
Yes, through mechanisms like incremental authorization or token exchange, which grant additional or narrower access without forcing a full new login.
Is authorization the same as access control?
No. Authorization is the decision about what's permitted. Access control is the full system around that decision, including enforcement, policy administration, and audit logging. Authorization sits inside access control rather than replacing it.
What's the difference between authorization and authentication?
Authentication verifies who someone is. Authorization decides what that verified identity can do. They run in sequence at sign-in, but authorization also has to run continuously afterward, on every protected action, not just once at login.
What are common authorization models (RBAC, ABAC, PBAC)?
RBAC grants access based on assigned roles. ABAC evaluates attributes of the user, resource, and environment for more granular decisions. Policy-based access control (PBAC) expresses rules as explicit policies that a decision point evaluates, which is the direction most modern authorization systems are moving toward because it decouples the rule from any single application.
Related terms
- Authentication (above)
- Access control (adjacent)
- Consent management (adjacent)
- Adaptive access (below)
See also
Entries that come up in the same conversation as Authorization.
.avif)