Every user interaction with an information system consists of two fundamental security steps: first, the system must establish who the user is (authentication), and then decide what that user is allowed to access (authorization). While authentication — logging in with a password, fingerprint, or hardware key — is an intuitive and widely understood process, authorization remains a far less obvious concept, even though in practice it is authorization that determines the actual security posture of an organization.
Authorization errors are among the most serious and most frequently exploited vulnerabilities in information systems. The OWASP Top 10 report has consistently placed “Broken Access Control” at the top of the list of the most critical threats to web applications. In this article, we explain what authorization is, how it differs from authentication, what access control models are used in practice, and what role authorization plays in Zero Trust architecture.
What is Authorization?
Authorization is the process of verifying whether an authenticated user, system, or process has the permissions to perform a specific operation on a specific resource. In other words, authorization answers the question: “Is this entity allowed to do this?”
Authorization is always the second step in the security chain — it follows authentication. The user first proves their identity (e.g., by providing a username and password), and then the system checks its policy and permissions database to determine what operations are allowed for that specific user. Authorization applies not only to humans — in modern architectures, it also covers applications, microservices, IoT devices, and automated processes that must obtain permissions to communicate with other system components.
Key concepts related to authorization include:
- Subject — who is requesting access (user, application, service).
- Resource/Object — what the subject wants to access (file, database, API endpoint, function).
- Action — what the subject wants to do with the resource (read, write, delete, execute).
- Policy — a rule defining whether a given subject can perform a given action on a given resource.
Authentication vs. Authorization — Key Differences
Although authentication (AuthN) and authorization (AuthZ) are closely related and appear together in virtually every system, they are fundamentally different processes. Confusing them leads to serious security design errors.
| Criterion | Authentication (AuthN) | Authorization (AuthZ) |
|---|---|---|
| Question | Who are you? | What can you do? |
| Purpose | Identity verification | Permission verification |
| Sequence | First step | Second step (after authentication) |
| Input data | Credentials (password, biometrics, token) | Policies, roles, attributes |
| Result | Identity confirmed or rejected | Access granted or denied |
| Protocols | SAML, OpenID Connect, FIDO2/WebAuthn | OAuth 2.0, XACML, OPA |
| Variability | Identity is constant (I am the same user) | Permissions change depending on context |
| Example | Logging in with a fingerprint | Access to the “Finance” folder only for accountants |
A simple analogy is a hotel: authentication is the reception desk that verifies your identity and issues a key card. Authorization is the card’s configuration — it opens the door to your room but not to the neighboring room or the maintenance area.
Access Control Models
In practice, organizations use various authorization models that define how permissions are assigned and enforced. The choice of model depends on the organization’s complexity, regulatory requirements, and the level of control granularity needed.
DAC — Discretionary Access Control
A discretionary model where the resource owner independently decides who has access. Example: a user sharing a file in Google Drive with specific people. DAC is simple but difficult to manage at scale and susceptible to human error — an owner may accidentally share a confidential document with the wrong person.
MAC — Mandatory Access Control
A mandatory model where access is centrally controlled based on security labels (classifications). Both subjects and resources are assigned security levels (e.g., “confidential,” “secret,” “top secret”). A user with a “confidential” clearance cannot access a document classified as “secret.” MAC is used in government and military organizations (e.g., the Bell-LaPadula model).
RBAC — Role-Based Access Control
The most popular model in commercial organizations. Permissions are assigned to roles, and roles to users. For example:
- Role “Accountant” → access to the financial system (read, write).
- Role “Auditor” → access to the financial system (read-only).
- Role “IT Administrator” → full access to infrastructure.
The advantage of RBAC is simplicity of management — when a new employee joins the finance department, you simply assign them the “Accountant” role instead of configuring dozens of individual permissions. The disadvantage is limited granularity — RBAC does not account for context (e.g., location, time of day, device).
ABAC — Attribute-Based Access Control
An attribute-based model that makes authorization decisions based on multiple parameters simultaneously:
- Subject attributes — role, department, tenure, location.
- Resource attributes — classification, owner, data type.
- Context attributes — time of day, IP address, device type, session risk score.
- Action attributes — read, write, delete, export.
Example ABAC policy: “An HR department employee from an office location, between 8:00 AM and 6:00 PM, may read employee personal data but cannot export it.” ABAC offers significantly greater granularity than RBAC but is more complex to implement and manage.
PBAC — Policy-Based Access Control
A policy-based model that centralizes authorization logic in an external policy engine. Policies are defined declaratively in languages such as Rego (Open Policy Agent), Cedar (Amazon), or XACML. PBAC enables dynamic, context-aware authorization decisions and is the foundation of modern Zero Trust architectures.
Access Control Model Comparison
| Model | Granularity | Complexity | Context-awareness | Typical Use |
|---|---|---|---|---|
| DAC | Low | Low | None | File systems, small teams |
| MAC | High | High | Limited | Military, government, critical infrastructure |
| RBAC | Medium | Medium | None | Commercial organizations, ERP, CRM |
| ABAC | Very high | High | Full | Large organizations, regulated sectors |
| PBAC | Very high | High | Full | Microservices, cloud, Zero Trust |
OAuth 2.0 and JWT — Authorization in Applications
OAuth 2.0 is the most popular authorization protocol in web and mobile applications. It allows third-party applications to obtain limited access to a user’s resources without exposing their password. When you click “Sign in with Google” in an application, OAuth 2.0 manages the authorization process.
Key elements of OAuth 2.0:
- Resource Owner — the user who owns the resources (e.g., data on Google Drive).
- Client — the application requesting access to resources.
- Authorization Server — the server issuing access tokens (e.g., Google OAuth).
- Resource Server — the server storing resources (e.g., Google Drive API).
- Access Token — a token authorizing the client to access resources.
- Scope — the permission scope (e.g., “read files only,” “read and write contacts”).
JWT (JSON Web Token) is a token encoding standard commonly used with OAuth 2.0. A JWT token contains three parts: a header (algorithm, type), payload (user data, permissions, expiration time), and a cryptographic signature. Thanks to the signature, a server can verify token authenticity without querying a database — which is critical for performance in microservice architectures.
Common threats related to OAuth 2.0 and JWT include: token hijacking, over-scoping (excessively broad permission scopes), missing signature validation, excessively long token lifetimes, and CSRF vulnerability in the authorization code flow.
SAML and Authorization in Federated Environments
SAML (Security Assertion Markup Language) is an XML standard that enables the exchange of authentication and authorization information between an Identity Provider (IdP) and a Service Provider (SP). SAML is the foundation of Single Sign-On (SSO) in enterprise environments.
In the context of authorization, SAML transfers user attributes (roles, groups, permissions) from the IdP to the SP in the form of assertions. The service provider makes authorization decisions based on these attributes — for example, granting access to the administration module if the SAML assertion contains an “Administrator” role.
Principle of Least Privilege
The Principle of Least Privilege (PoLP) is a fundamental security principle stating that every subject (user, application, process) should possess only those permissions that are necessary to perform their current tasks — and nothing more.
PoLP minimizes the attack surface: if a user account is compromised, the attacker gains access only to a limited set of resources, not the entire infrastructure. In practice, implementing PoLP requires:
- Regular access reviews — quarterly verification that granted permissions are still needed.
- Just-in-Time (JIT) access — granting permissions only for the duration of a specific task, then automatically revoking them.
- Separation of Duties (SoD) — no single user should control an entire critical process (e.g., approving and executing payments).
- Integration with PAM systems — privileged access management ensures control over accounts with the highest permissions (root, administrator).
Authorization in the Zero Trust Model
In traditional architectures, authorization was based on network location — “if you are on the corporate network, you have access.” The Zero Trust model fundamentally rejects this assumption. The principle of “never trust, always verify” means that authorization is continuous, contextual, and dynamic.
Key principles of Zero Trust authorization:
- Continuous verification — authorization is not a one-time event. Every access request is verified independently, even if the user was previously authorized.
- Context-aware decisions — the system considers multiple signals: identity, device (is it managed? does it have current patches?), location, time of day, user behavior (anomalies), and session risk level.
- Microsegmentation — resources are isolated, and access to each requires separate authorization. Access to server A does not automatically grant access to server B.
- Least privilege — the user receives the minimum set of permissions for the minimum duration.
In practice, Zero Trust authorization uses Policy Decision Points (PDP) — central policy engines that evaluate every access request in real time based on defined policies and contextual signals. Technologies such as Open Policy Agent (OPA), Google BeyondCorp, and Azure Conditional Access implement these principles at enterprise scale.
Common Authorization Vulnerabilities
Authorization errors are among the most frequently exploited vulnerabilities in applications and IT systems. Understanding typical attack vectors is critical for effective defense.
IDOR — Insecure Direct Object Reference
IDOR is a vulnerability where an application allows a user to access another user’s resources through simple identifier manipulation. Example: changing api/invoices/1234 to api/invoices/1235 allows reading another customer’s invoice. The application authenticates the user but does not verify whether they have the right to access the specific object.
Broken Access Control
This term encompasses a range of authorization-related vulnerabilities:
- Vertical privilege escalation — a regular user gains access to administrator functions (e.g., an admin panel accessible without role verification).
- Horizontal privilege escalation — a user gains access to resources of another user at the same permission level.
- Missing function-level access control — an API endpoint is accessible without permission checks.
- Path traversal — file path manipulation to access resources outside the permitted scope.
Preventing Authorization Vulnerabilities
Effective defense against authorization vulnerabilities requires a layered approach:
- Deny by default — every access must be explicitly permitted. The absence of a defined rule means denial.
- Centralize authorization logic — do not implement permission checks in multiple code locations. Use a central middleware or policy engine.
- Security testing — regular security audits and penetration tests should include privilege escalation and IDOR scenarios.
- Logging and monitoring — every access denial should be logged and analyzed. An increase in denials may signal an attack attempt.
Authorization and Regulatory Compliance
Proper authorization implementation is required by most information security and data protection regulations:
- NIS2 — requires implementation of “appropriate and proportionate technical and organizational measures” for access control. Organizations subject to the NIS2 directive must demonstrate they apply the principle of least privilege and regularly review permissions.
- GDPR — Article 25 (privacy by design) and Article 32 (security of processing) require appropriate access controls for personal data.
- ISO 27001 — Control A.9 (Access Control) defines requirements for access control policies, user access management, and system and application access control.
- PCI DSS — Requirement 7 (Restrict access to cardholder data) mandates implementing need-to-know-based access control.
Best Practices for Authorization Implementation
Implementing an effective authorization system requires addressing both technical and organizational aspects:
- Define the access control model appropriate for your organization. For most companies, RBAC with ABAC elements is a good balance between simplicity and granularity.
- Centralize permission management in an IAM (Identity and Access Management) system. Avoid distributed permission configurations across individual applications.
- Automate the permission lifecycle — provisioning during onboarding, modification during role changes, deprovisioning during offboarding.
- Implement regular access reviews — quarterly, managers verify their teams’ permissions.
- Apply Just-in-Time access for privileged permissions — an admin account should not be active 24/7.
- Log all authorization decisions — who, what, when, with what result.
- Test authorization — penetration tests and automated security tests should include IDOR, privilege escalation, and broken access control scenarios.
Summary
Authorization is the foundation of security for every information system. Without proper authorization, authentication loses its purpose — we know who the user is, but we do not control what they can do. In an era of growing cyber threats, regulations (NIS2, GDPR), and distributed infrastructure (cloud, microservices, remote work), organizations must transition from simple, static access control models to dynamic, context-aware authorization systems based on Zero Trust principles.
Investment in appropriate IAM/PAM tools, implementation of the principle of least privilege, and regular permission audits are not a cost but a necessity — especially in light of the steadily increasing number of attacks that exploit authorization errors as the primary compromise vector.
Frequently Asked Questions (FAQ)
What is the difference between authorization and authentication?
Authentication answers “who are you?” — it verifies a user’s identity using credentials (password, biometrics, token). Authorization answers “what can you do?” — it determines permissions to resources based on roles, attributes, and policies. Authentication always occurs before authorization.
What is the RBAC model?
RBAC (Role-Based Access Control) is an access control model where permissions are assigned to roles, and roles to users. For example, the “Accountant” role has access to the financial system. It is the most popular model in commercial organizations due to its management simplicity — instead of configuring permissions for each user, you simply assign them the appropriate role.
What is OAuth 2.0?
OAuth 2.0 is an authorization protocol that allows third-party applications to access a user’s resources without exposing their password. Example: “Sign in with Google” — the application receives a limited access token with a defined permission scope instead of the user’s full login credentials.
What is the principle of least privilege?
The Principle of Least Privilege (PoLP) is a fundamental security principle stating that a user should only have the permissions necessary to perform their current tasks — and nothing more. This minimizes the attack surface in case of account compromise and limits potential damage from human error.
How does authorization work in the Zero Trust model?
In Zero Trust architecture, authorization is continuous and context-aware — every access request is verified regardless of the user’s location or previous authorizations. The system considers multiple signals: identity, device, location, time of day, and user behavior. The principle of “never trust, always verify” applies to every resource and every request.
