Cybersecurity glossary
What is Authorization?
Learn what authorization is, how access decisions differ from authentication, models such as RBAC and ABAC, common authorization failures, and controls that enforce least privilege.
Definition
Authorization is the process of deciding whether an authenticated (or anonymous) subject is allowed to perform a specific action on a resource, based on policies, roles, attributes, ownership, or other access-control rules.
Why authorization determines real security outcomes
Knowing who someone is only half the story. Authorization answers what that identity may touch: which records, which actions, which tenants, and under which conditions.
Most high-impact application breaches that look like “hacks” are authorization failures—object IDs guessed, admin flags trusted from the client, or roles that grew too broad over years of convenience.
How an authorization decision is made
Identify the subject
Use the authenticated principal, service identity, or an explicit anonymous context.
Identify the action and resource
Normalize the request into something policy can evaluate, such as invoices:read on invoice 4821.
Gather attributes and context
Collect roles, ownership, tenant, device posture, time, risk score, and token scopes.
Evaluate policy
A policy engine, middleware, or data-layer check returns allow, deny, or require step-up.
Enforce and log
Deny by default on failure, apply the decision server-side, and record auditable outcomes.
Authorization models teams actually use
RBAC
Permissions grouped into roles. Simple to start with, but roles often accumulate excess rights.
ABAC
Policies evaluate attributes of users, resources, and environment for finer decisions.
ReBAC / relationships
Access follows graphs such as owner, member, or parent-child resource links.
ACLs
Per-object permission lists remain common in filesystems and collaborative documents.
OAuth scopes
Tokens carry delegated permission labels that resource servers must enforce.
Policy-as-code
Central engines keep rules versioned, testable, and consistent across services.
Authentication vs authorization vs related controls
| Control | Purpose | Typical failure |
|---|---|---|
| Authentication | Prove identity | Account takeover via weak login |
| Authorization | Limit actions and resources | User A reads User B’s data by ID |
| Least privilege | Minimize granted rights | Everyone gets admin-like roles |
| Audit / accounting | Record what happened | No trail for privilege abuse |
Where authorization commonly breaks
- Missing server-side checks — UI hides buttons, but APIs accept any authenticated caller.
- Insecure direct object references — sequential IDs without ownership or tenant checks.
- Confused deputy / over-scoped tokens — clients or services act with broader rights than intended.
- Role explosion and drift — temporary elevated access never expires.
- Multi-tenant leakage — filters forget the tenant boundary on one query path.
- Trusting the client —
isAdmin=trueor edited JWT claims accepted without verification.
Practical enforcement checklist
- Deny by default; grant explicit permissions for each sensitive action.
- Enforce authorization in the API and data layer, not only in frontend routes.
- Bind every object access check to ownership, tenant, and relationship rules.
- Keep roles small; prefer just-in-time elevation for administrative tasks.
- Validate OAuth scopes and token audience on every resource-server request.
- Separate authentication strength from authorization breadth—require step-up for sensitive ops.
- Automate joiner-mover-leaver reviews so unused permissions are revoked.
- Log allow/deny decisions for privileged actions with subject, resource, and policy version.
Designing authorization for change
Organizations and product surfaces evolve. Hard-coded if (role === 'admin') checks scattered across services become inconsistent. Centralize policy where possible, keep decision points close to the data, and test negative cases as seriously as happy paths.
Authorization is also continuous: a valid session from yesterday may no longer deserve the same rights after a role change, risk spike, or token scope reduction.
The practical takeaway
Authorization turns a verified identity into bounded capability. Strong authentication without strong authorization still leaks data and enables privilege abuse.
Define clear policies, enforce them server-side on every path, minimize standing privileges, and verify that tokens, roles, and object references cannot quietly expand what a subject can do.
Related security terms
Authentication
Verifies identity before authorization can meaningfully apply.
Least Privilege
Grant only the minimum permissions needed for a task.
Attribute-Based Access Control
Policy model that evaluates attributes of users, resources, and context.
OAuth 2.0
Delegated authorization framework that issues scoped access tokens.
Privileged Access Management (PAM)
Controls for elevated administrative permissions.
Frequently asked questions
What is authorization in simple terms?
Authorization is the system deciding what you are allowed to do after (or without) proving who you are—for example reading a file, approving a payment, or calling an admin API.
What is the difference between authentication and authorization?
Authentication proves identity. Authorization grants or denies permissions for actions and resources. A correct login does not automatically mean full access.
What are common authorization models?
Role-based access control (RBAC), attribute-based access control (ABAC), relationship-based models, access-control lists, and policy-as-code engines that combine several approaches.
What is broken authorization?
Failures such as insecure direct object references, missing server-side checks, overly broad roles, or trusting client-supplied permission flags that let users exceed their intended privileges.
How does OAuth relate to authorization?
OAuth 2.0 is a framework for delegated authorization: clients receive access tokens with limited scopes instead of the resource owner’s password.
Should authorization be enforced only in the UI?
No. Hide unauthorized actions in the UI for usability, but enforce every decision on the server or policy engine that protects the data and APIs.
How do you test authorization?
Attempt horizontal and vertical privilege escalation across object IDs, roles, tenants, and API clients; verify deny-by-default and that tokens cannot exceed their scopes.
References
Explore authoritative guidance and frameworks related to authorization.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.