In modern application security, it has become all about identity. Companies invest in Multi-Factor Authentication (MFA), Single Sign-On (SSO), Conditional Access, and Federated Identities to improve confidence in the identity of the individual accessing their systems.
These are vital components, but they are only addressing one component of the access control challenge.
Authentication helps you understand the question “Who are you?” Authorization helps you determine the answer to “What are you allowed to do?”
This is crucial because you can have a very secure application with robust authentication in place that can still expose sensitive data or privileged actions via weak authorization. The legitimate user is able to log in and pass all identity checks, yet the user has access to something that is outside their allowed scope.
With Zero Trust, authentication should never be considered the end of the verification journey.
Authentication Establishes Identity. Authorization Enforces Boundaries.
Authorization tells whether an authenticated identity should be allowed to execute a specific action against a specific resource.
It may seem simple, but in reality, it quickly becomes complex.
Modern applications often include many user types, business units, regions, admin roles, service identities, and even API consumers. Consequently, access control cannot depend on the fact that the user is authenticated. Access control must take into consideration ownership, role, entitlement, business context, and the sensitivity of the action.
For instance, the customer is entitled to view his records but not others. The support engineer may need read access to account details but should not have access to modify financial data. The departmental administrator can manage users in a specific organizational unit without having the privileges across the tenant.
When this is not taken into account by the application, the consequence is broken authorization.
The importance of this risk is so high that broken access control is A01 in OWASP Top 10:2025. In the API world, the issue becomes even more visible in issues like Broken Object Level Authorization (API1:2023) and Broken Function Level Authorization (API5:2023).
Why APIs Make Authorization More Critical
APIs are making the authorization challenge more pronounced because they expose business logic and data via structured and repeatable requests.
Consider the following request:
GET /api/customers/1457
The application may be able to confirm that the requesting user is authenticated. But that is not enough. The application needs to confirm whether that user is authorized to access customer 1457.
If modifying the identifier to:
GET /api/customers/1458
returns another customer’s information without an ownership or entitlement check, the authentication mechanism has worked correctly while the authorization model has failed.
The same problem applies to functions. An ordinary user may legitimately call:
GET /api/profile
but should not be able to perform an administrative operation simply by discovering or manually invoking an endpoint such as:
DELETE /api/users/128
Security therefore cannot depend on whether a button is hidden in the interface or whether an endpoint is absent from the normal user workflow. Authorization must be enforced server-side for every sensitive operation.
The underlying principle is simple: possession of a valid session must not imply permission to every reachable resource.
Zero Trust Must Continue Beyond the Login Event
One of the most important ideas behind Zero Trust is that trust should not be granted permanently because a user, device, or workload previously passed a verification check.
Yet some Zero Trust implementations become disproportionately focused on identity-provider controls and network architecture.
A user may pass MFA, connect from a compliant device, satisfy a conditional access policy, and originate from an approved location. None of those factors, on their own, establish that the user should be allowed to access a particular data object or invoke a sensitive business function.
This is where Zero Trust has to move from architecture into application logic.
Every sensitive request should be treated as an access decision.
- Who is making the request?
- What resource is being requested?
- What action is being attempted?
- What entitlement or role authorizes that action?
- Does the requested operation align with the user’s current business context?
- Should that permission still be considered valid?
This is a more mature interpretation of “never trust, always verify.” Verification should be continuous and contextual rather than concentrated at the point of authentication.
Least Privilege Must Extend Into Business Logic
Least privilege is often discussed in relation to infrastructure, privileged accounts and administrative roles, but application security requires the same discipline.
Users should receive only the application functions and data necessary to perform their responsibilities.
That means avoiding broad roles where more granular permissions are practical, separating administrative capabilities from ordinary user activity and periodically reviewing whether access remains justified.
The same principle applies to machine identities and service-to-service access. APIs increasingly interact with other APIs, automation platforms and cloud services. Those workloads require defined authorization boundaries just as human users do.
A service identity with excessive privileges may represent just as much risk as an overprivileged administrator.
Authorization decisions should therefore be explicit rather than assumed.
Design Authorization as a Security Control, Not a Feature
One of the common weaknesses in application design is that authorization is treated as a feature implemented after the core functionality has already been built.
It should instead be designed as a security control from the beginning.
Developers need clear access-control requirements. Security teams need visibility into sensitive operations and privilege boundaries. Identity teams need to ensure that roles and entitlements remain meaningful over time.
For higher-risk applications, this may require moving beyond simple role-based access control and considering additional context such as resource ownership, device state, transaction sensitivity or risk signals.
The objective is not to make authorization unnecessarily complex. It is to ensure that access decisions reflect the actual business rules the application is expected to enforce.
Visibility and Monitoring Matter Too
Authorization is not only about preventing unwanted actions. Organisations also need visibility into attempted violations.
Repeated requests for resources outside a user’s scope, unusual administrative operations and changes in privilege should be logged and monitored.
These events can provide useful indicators of compromised accounts, insider misuse or application probing.
A mature access-control model therefore combines prevention with detection.
Identity platforms establish who the requester is. Application authorization determines what that requester may do. Logging and monitoring help identify when those boundaries are being tested or abused.
Together, these controls create a stronger enforcement model than authentication alone.
A More Complete Zero Trust Model
Zero Trust should not stop at the identity provider.
A mature application-security model combines strong authentication with granular authorization, least privilege, contextual access decisions and continuous monitoring.
This requires collaboration across development, security and identity teams.
Identity establishes confidence in the requester.
Authorization enforces business boundaries.
Monitoring provides visibility into attempted violations.
Governance ensures that permissions remain aligned with legitimate business requirements.
When these disciplines operate together, Zero Trust becomes more than a gateway or network architecture. It becomes an access-control model that follows the identity through to the individual transaction.
Conclusion
The security industry has made substantial progress in strengthening authentication. Multi-factor authentication, single sign-on and identity-aware access controls have all raised the cost of impersonating legitimate users.
But authentication alone cannot determine whether an action should be permitted.
An authenticated identity may still be overprivileged, compromised or attempting to perform an operation outside its legitimate scope.
That is why authorization must be treated as a first-class security control.
For modern applications and APIs, the most important access-control question is no longer simply:
“Who are you?”
It is:
“Are you authorized to perform this action, on this resource, under these conditions, right now?”
Zero Trust becomes meaningful at the application layer only when that question is answered consistently.
References
- OWASP Top 10:2025 – A01 Broken Access Control: https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/
- OWASP API Security Top 10:2023 – API1 Broken Object Level Authorization: https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/
- OWASP API Security Top 10:2023 – API5 Broken Function Level Authorization: https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/
