Authorization is the process of deciding what an already-authenticated identity is permitted to do. Once a system knows who you are, authorization determines what you are allowed to access and which actions you may take — read this file, edit that record, delete nothing. It is the rule-checking layer that stands between a verified user and the resources they want to touch. Every time an application shows you a button but greys out another, or lets one colleague approve an expense while blocking a second, authorization is quietly doing its job in the background.
Why It Matters
Authorization is what turns "we know who you are" into "here is exactly what you may do." Without it, verifying identity would be pointless: a system where every authenticated user could do everything is only as safe as its least-trusted account. Good authorization enforces the principle of least privilege — the idea that each identity should have only the access it genuinely needs, and no more.
That principle is the single most effective way to contain damage. If an attacker steals the credentials of an employee who can only read one dataset, the blast radius is that one dataset. If they steal the credentials of an over-privileged account that can reach everything, a single compromise becomes a catastrophe. Authorization also underpins privacy and compliance: regulations frequently demand that sensitive records be reachable only by people with a legitimate need, and that demand is enforced through authorization rules. When you hear about a breach where "an attacker moved laterally" through a network, weak authorization is very often what let them.
A Simple Analogy: A Hotel Keycard
Think of authorization like a hotel keycard. Checking in at the front desk is authentication — the staff confirm you are the guest on the reservation. The keycard you receive afterward is authorization: it opens your room and the gym, but not other guests' rooms, not the staff office, and not the rooftop suite. Two guests can be equally "checked in" yet hold cards that open completely different doors. The card does not care who you are in the abstract; it enforces a specific set of permissions tied to your stay.
How It Works
Authorization happens after authentication and typically follows a check like this:
1. Request arrives → user "jordan" wants to DELETE /invoices/42
2. System identifies actor → session token confirms this is jordan
3. System gathers context → jordan's roles, the resource's owner, the action
4. Policy engine evaluates → "may jordan delete invoice 42?"
5. Decision returned → ALLOW or DENY
The heart of the system is the policy check in step 4. Different models answer that question in different ways:
- Access control lists (ACLs) attach an explicit list of who-can-do-what directly to each resource.
- Role-based access control (RBAC) grants permissions to roles — like "editor" or "admin" — and assigns users to those roles.
- Attribute-based access control (ABAC) evaluates flexible rules over attributes of the user, resource, action, and environment.
Whichever model is used, a well-designed system checks authorization on every sensitive request, on the server side, rather than trusting the interface to hide forbidden options. Hiding a delete button in the browser is a convenience, not a control; a determined user can craft the request directly, so the real decision must live where it cannot be bypassed.
Key Things to Know
A few distinctions prevent common confusion:
| Concept | What it means | Why it matters |
|---|---|---|
| Least privilege | Grant only the access truly needed | Limits damage from any single compromise |
| Coarse-grained | Broad permissions (e.g., "all invoices") | Simple, but risks over-provisioning |
| Fine-grained | Narrow permissions (e.g., "own invoices") | More precise, more to manage |
| Server-side check | Decision enforced on the backend | Cannot be bypassed by the client |
The most important takeaway is that authorization must be enforced on the server and applied consistently. A large class of serious vulnerabilities — often called broken access control — comes from a system that authenticates users correctly but then forgets to properly check whether they are permitted to perform a specific action.
How Safeguard Helps
Authorization logic is frequently built on open-source frameworks and libraries that manage roles, policies, and permission checks. A flaw in one of those components can silently weaken the rules protecting your data, and such flaws are not always obvious from the outside. Safeguard's software composition analysis catalogs the libraries your application depends on and flags any carrying known vulnerabilities, including those in the access-control layer.
Since a long list of findings is hard to prioritize, Griffin AI highlights the flaws sitting in code paths your application actually executes and explains the risk in plain language. To understand the related building blocks — authentication, roles, and attribute-based rules — the concepts library covers them clearly. To analyze your own dependencies, create a free account, or work through the fundamentals in Safeguard Academy.
Frequently Asked Questions
How is authorization different from authentication?
Authentication verifies who you are; authorization decides what you may do. They run in order: a system authenticates you first, then authorizes each action you attempt. A correct password gets you logged in, but it is authorization that determines whether your account can open a particular record or perform a specific operation.
What is the principle of least privilege?
It is the practice of giving every identity only the access it genuinely needs to do its job, and nothing extra. Least privilege limits the harm any single compromised account can cause. If a breached account can reach only one small area, the damage stays contained rather than spreading across the whole system.
What is broken access control?
Broken access control is the class of flaws where a system fails to properly enforce authorization — for example, letting a user view or modify records they should not be able to reach by directly requesting them. It is one of the most common and serious categories of web application weakness, precisely because the check is easy to forget or implement inconsistently.
Which authorization model should I use?
It depends on your needs. Role-based access control is simple and widely understood, making it a strong default for many applications. Attribute-based access control offers more flexibility for complex, context-sensitive rules but is harder to manage. Many systems combine approaches. The right choice balances how fine-grained your rules must be against how much complexity your team can maintain.