Authorization is the process of deciding whether an identity is permitted to perform a specific action on a specific resource, based on a policy and the context of the request. In cybersecurity, and particularly in identity and access management, it follows authentication: authentication establishes who is making the request, while authorization determines what that identity may do.
Every access decision can be reduced to a question with four parts: a subject (a user, service or device), an action (read, write, delete, approve), a resource (a file, record, API endpoint or system) and the context (time, location, device state, risk level). Authorization answers that question with permit or deny, and well-designed systems make that answer consistent, auditable and as narrow as the task allows.
How authorization decisions are made
An authorization decision is produced by evaluating a policy against the attributes of a request. Mature architectures separate this work into distinct functions so that the rules live in one place while enforcement happens wherever the resource is exposed.
The reference model described in the XACML standard and in NIST guidance on attribute-based access control names these four functions explicitly. The same separation appears in modern policy engines such as Open Policy Agent and in cloud identity services, even when the terminology differs.
| Component | Role in the decision | Typical implementation |
|---|---|---|
| Policy enforcement point | Intercepts the request and applies the verdict | API gateway, middleware, service mesh sidecar |
| Policy decision point | Evaluates policy and returns permit or deny | Policy engine, authorization service |
| Policy information point | Supplies attributes needed for the decision | Directory, HR system, device inventory |
| Policy administration point | Stores, versions and publishes policy | Policy repository, admin console |
A safe design applies default deny: if no rule grants access, or if the decision point is unreachable, the request fails. Systems that fail open under load or during an outage convert an availability problem into a confidentiality breach.
Authorization models and when each fits
Authorization models differ in what the policy is expressed in terms of: owners, roles, attributes or relationships. The choice determines how well the system scales as users, resources and rules multiply.
| Model | Decision based on | Strength | Main weakness |
|---|---|---|---|
| DAC | Owner grants rights to others | Simple and flexible for files | Weak central control |
| MAC | System-enforced labels and clearances | Strong confinement | Rigid and costly to administer |
| RBAC | Roles assigned to users | Easy to audit at moderate scale | Role explosion in complex organizations |
| ABAC | Attributes of subject, resource and context | Fine-grained and context-aware | Policies are harder to test and explain |
| ReBAC | Relationships between objects in a graph | Natural for sharing and hierarchies | Requires a consistent relationship store |
In practice most organizations run a hybrid: RBAC for coarse job functions, attribute or relationship rules for data-level restrictions such as tenant, region or record ownership. RBAC has its own page as a neighboring Term, so here it matters mainly as the most widely used baseline.
Authorization compared with neighboring identity concepts
Authorization is often confused with the mechanisms that come before it. Authentication, MFA, SSO and passkeys all concern proving identity; none of them by themselves restricts what a proven identity can reach.
| Concept | Question it answers | Relation to authorization |
|---|---|---|
| Authentication | Is this really the claimed identity | Provides the subject that authorization evaluates |
| MFA | Is the proof strong enough | Can be a condition inside an authorization policy |
| SSO | Can one login serve many applications | Carries identity, each application still authorizes |
| OAuth 2.0 scopes | What has the user delegated to a client | Delegated authorization for APIs |
| Accounting | What did the identity actually do | Records decisions for audit and investigation |
A frequent source of confusion is OAuth 2.0, which is a delegated authorization framework, not an authentication protocol. An access token says what a client may do on behalf of a user; OpenID Connect adds the identity layer on top of it.
Designing authorization in practice
Good authorization design starts from the principle of least privilege: each identity receives only the permissions its current task requires, for only as long as it needs them. The related principle of separation of duties prevents a single identity from both initiating and approving a sensitive action.
- Centralize policy, distribute enforcement: one policy source, many enforcement points close to the resource.
- Check on every request: authorize object access on the server, not only when the page or menu is rendered.
- Prefer short-lived grants: just-in-time elevation expiring in minutes or hours instead of standing administrator rights.
- Review access periodically: recertify entitlements, often quarterly for privileged accounts.
- Log every decision: record subject, action, resource, verdict and the policy version that produced it.
Token-based systems need extra care. A JSON Web Token carries claims that stay valid until expiry, so access token lifetimes of roughly 5 to 60 minutes are common, with refresh tokens and revocation lists covering longer sessions.
Common authorization failures
Broken access control is the most frequent category of serious web application weakness, and it ranks first in the OWASP Top 10 of 2021. Most failures come from missing checks, not from flawed cryptography.
| Flaw | What happens | Fix |
|---|---|---|
| Insecure direct object reference | Changing an ID in a URL exposes another user’s record | Verify ownership or relationship on every object access |
| Privilege escalation | A regular user reaches administrative functions | Enforce role checks on the server for every function |
| Client-side enforcement only | Hidden buttons stop nobody calling the API directly | Repeat every check in the backend |
| Privilege creep | Users accumulate rights from past roles | Periodic access reviews and automated deprovisioning |
| Confused deputy | A trusted service acts with its own rights for an untrusted caller | Propagate the caller identity and authorize it |
Testing authorization requires negative test cases: requests that should be refused. Automated suites that only confirm permitted actions succeed will never detect an access control gap.
A non-technical view
Think of a hotel. Showing your passport at the front desk proves who you are, which is authentication. The key card you receive is authorization: it opens your room, the gym and the pool, but not other guests’ rooms or the staff office.
The hotel decides in advance which doors each card opens, and it can change or cancel the card at any time. Authorization is simply the set of rules about which doors your identity opens, checked every time you try a handle.
A concrete example
A regional hospital gives clinicians access to an electronic health record system after they sign in with single sign-on and a hardware security key. Authentication is identical for everyone, but authorization differs sharply. A nurse may read and update records only for patients on the assigned ward, a physician may also prescribe, and a billing clerk sees invoices but not clinical notes.
The hospital implements this with roles for job functions and attribute rules for ward, shift and treatment relationship. An emergency break-glass permission lets any clinician open a record outside those rules, but each use is logged and reviewed within 24 hours. When an internal audit later finds an employee browsing a celebrity patient’s file through break-glass without a clinical reason, the decision log identifies the access within minutes, and the hospital revokes the account the same day.