Overview
Authorization decides what an authenticated identity is allowed to do. Authentication opens the door; authorization decides which rooms you may enter. Confusing the two — or enforcing authorization only in the user interface — is a classic and dangerous mistake.
Learning objectives
- Define authorization and separate it from authentication.
- Describe common authorization models.
- Understand why authorization must be enforced server-side.
Core concept
Once a system knows who you are (authentication), authorization answers what may you access and do? Common models:
- Role-Based Access Control (RBAC) — permissions are attached to roles (e.g. "editor," "admin"), and users are assigned roles. Simple and widely used.
- Attribute-Based Access Control (ABAC) — decisions use attributes (user department, resource sensitivity, time of day), enabling fine-grained rules.
- Discretionary / Mandatory access control (DAC/MAC) — the resource owner grants access (DAC), or a central policy enforces labels (MAC), common in high-security environments.
How it works
Every sensitive action should pass an authorization check on the server: "Does this identity have permission for this action on this resource?" The check must happen where the user cannot tamper with it — in the backend — not merely by hiding a button in the UI. Hiding a control is a usability aid, not a security control.
Practical example
In a blog platform, an authenticated reader and an authenticated author are both logged in (same authentication), but only the author is authorized to publish posts. If the "Publish" API does not re-check the role on the server, a reader could call it directly and publish — an authorization bypass. Enforcing the role check in the backend closes this.
Cybersecurity relevance
Broken access control is consistently among the most common and severe web vulnerabilities (it tops the OWASP Top 10). IDOR (Insecure Direct Object Reference) — accessing another user's record by changing an ID in a request — is a pure authorization failure you will study in the Web Security path.
Common mistakes
- Enforcing authorization only in the client (hiding buttons) while the API stays open.
- Trusting IDs from the request without checking the caller owns that resource (IDOR).
- Over-granting roles, giving users more power than their job needs.
Key takeaways
- Authorization determines what an authenticated identity may do.
- Models include RBAC, ABAC, and DAC/MAC.
- Authorization must be enforced server-side on every sensitive action; UI hiding is not security.
Check your understanding
- Explain the difference between authentication and authorization in one sentence each.
- Why is hiding a "delete" button in the UI not sufficient to prevent deletion?