Glossary
Authorization is the process of determining what an authenticated user (or service) is permitted to do (which resources they can access and which actions they can perform) after their identity has been verified. It’s the "what are you allowed to do?" step that follows authentication’s "who are you?", and it’s where access is actually granted or denied.
Authorization is easy to describe and surprisingly hard to do well at scale. As applications grow more complex and architectures shift toward zero trust and APIs, deciding (correctly, for every request) what each identity may do has become one of the thornier problems in security.
The two are sequential and distinct. Authentication establishes identity (confirming you are who you claim). Authorization uses that established identity to decide permissions (what you can access). Authentication happens first, typically once at login; authorization happens continuously, on every request for a protected resource. Confusing them causes real vulnerabilities, strong authentication means nothing if authorization fails to properly restrict what the verified user can reach.
At its core, authorization compares a request against a policy: this user, attempting this action, on this resource, in this context, allowed or not? The policy can be simple (an admin flag) or richly conditional (based on roles, attributes, relationships, and risk). Increasingly, authorization decisions are externalized from application code into a dedicated policy engine or service that evaluates each request against centrally-managed rules, so logic isn’t scattered and inconsistent across the codebase.
Several models express "who can do what," each suited to different needs:
Real systems often combine these, matching the model to the sensitivity and complexity of what’s being protected.
Authorization failures are among the most common and damaging vulnerabilities, "broken access control" consistently tops industry risk rankings (it’s number one on the OWASP Top 10). Typical failures include letting a user change an ID in a URL to view another’s data, or an API endpoint that never checks whether the caller is entitled to the object requested. The lesson is that authorization must be enforced on every request, server-side, against the specific resource, never assumed because the user is authenticated or because the UI hides an option.
Two shifts are raising the stakes. Zero-trust architecture requires verifying every request rather than trusting a network location, which multiplies authorization decisions. And APIs and microservices mean far more entry points, each needing fine-grained checks. On top of that, AI agents acting on users’ behalf push authorization toward ephemeral, tightly-scoped grants: an agent should be allowed to do exactly one task, right now, and nothing more. This is why authorization has become its own discipline, with dedicated fine-grained authorization services and models, rather than a few permission checks buried in application logic.
What is authorization?
Determining what an authenticated user or service is allowed to do (which resources and actions they’re permitted) after identity is verified.
What’s the difference between authentication and authorization?
Authentication proves who you are; authorization decides what you can do. Authentication comes first, authorization on every request.
What are the main authorization models?
RBAC (by role), ABAC (by attributes), ReBAC (by relationships), and fine-grained authorization for per-resource control.
What is broken access control?
A failure where authenticated users can reach resources or actions they shouldn’t, the top item on the OWASP Top 10.
Why is authorization becoming harder?
Zero trust and APIs multiply per-request decisions, and AI agents require tightly-scoped, ephemeral permissions.
Related: Authentication vs. Authorization · Fine-Grained Authorization (FGA) · Role-Based Access Control (RBAC) · Attribute-Based Access Control (ABAC) · Zero Trust · Principle of Least Privilege
