Authorization and authentication separation remains a control boundary

At a glance

What this is: This is an IAM perspective on why authentication and authorization are separate systems, and the key finding is that mixing them in code is a major driver of broken access control.

Why it matters: It matters because identity teams, architects, and developers need clean control boundaries for human, NHI, and machine access decisions, or least privilege fails at the application layer.

👉 Read Ory's full analysis of authentication and authorization differences

Context

Authentication and authorization are different security functions, even though teams often discuss them as if they were interchangeable. Authentication establishes who or what the requester is, while authorization decides what that verified identity may do. In IAM programmes, that distinction is foundational because it determines how identity claims become access decisions across human users, service accounts, and machine-to-machine workflows.

The governance gap is not academic. When permission checks are embedded inside authentication logic, one misconfigured route or middleware path can silently widen access. That failure pattern matters for modern identity stacks because the same separation principle underpins human IAM, NHI governance, and the policy checks that protect service-to-service APIs and agent-facing controls.

Key questions

Q: How should security teams separate authentication from authorization in practice?

A: Treat authentication as the control that proves identity, and authorization as the control that limits actions after identity is established. In practice, that means different policy owners, different review cadences, and different telemetry. For NHIs, the distinction is critical because valid machine credentials can still carry excessive privilege if access scope is not checked independently.

Q: Why does broken access control happen even when login works correctly?

A: Because login only proves identity. If the application never checks whether that identity is allowed to perform the specific action, authenticated users can inherit access they should not have. The failure is usually in the policy layer or in the code path that forgets to call it, not in the credential check itself.

Q: What do organisations get wrong about role-based access control?

A: They often let roles accumulate exceptions until the role catalogue no longer reflects actual work. That creates hidden over-privilege even when the policy looks structured. RBAC must be continuously reconciled with job duties, application ownership, and review evidence, or it becomes a broad access bundle instead of a control model.

Q: What is the difference between a valid session and valid authorisation?

A: A valid session means authentication succeeded and the system recognizes the requester as a verified identity. Valid authorisation means a separate policy engine has confirmed that the identity may perform the specific action on the specific resource. One proves who the requester is, the other proves what they are allowed to do.

Technical breakdown

Authentication creates the trust input for authorization

Authentication validates credentials and issues a session, token, or assertion that represents a verified identity. Authorization then evaluates that identity against policy, resource, and context to permit or deny the requested action. The output of authentication is therefore not access itself, but the input that makes access control possible. This sequence is an architectural dependency, not a naming preference, and it must hold whether the actor is a person, service account, certificate-bearing workload, or an AI-connected system using federated identity.

Practical implication: keep identity proofing and policy evaluation in separate services so each control can be tested, audited, and changed independently.

Broken access control starts when permission checks live in auth logic

A common failure mode is treating authentication as if it also enforced authorization. A developer checks whether a user is logged in, but never checks whether that user may perform the specific action or reach the specific resource. In that pattern, the system returns a valid session and then silently grants broader access than intended. The article correctly ties this to OWASP A01, because the issue is not failed login, it is failed policy enforcement after login. The same anti-pattern appears in API gateways, internal admin tools, and workload endpoints.

Practical implication: review every protected route for an explicit policy decision after authentication, not just a valid session check.

RBAC, ABAC, and ReBAC solve different authorization problems

Once authentication has produced a trusted identity, authorization can be expressed through roles, attributes, or relationships. RBAC works when access patterns are stable and role hierarchies are manageable. ABAC fits dynamic conditions such as environment, sensitivity, or compliance state. ReBAC fits collaboration-heavy systems where relationships drive access. The key point is that none of these models replaces authentication, and none should be mixed into login logic. Separate modeling prevents role explosion, policy sprawl, and the false assumption that proving identity also proves permission.

Practical implication: choose the authorization model that fits the resource, then bind it to a verified identity after authentication completes.

Threat narrative

Attacker objective: The attacker objective is to turn ordinary authenticated access into broader application or administrative access without needing to defeat the login system itself.

1. Entry occurs when a requester successfully authenticates and receives a session or token that downstream services trust as proof of identity.
2. Escalation happens when the application treats authentication as sufficient authorization and skips the policy check that should limit the action or resource.
3. Impact is broken access control, where authenticated users inherit permissions they were never meant to have and sensitive actions become reachable.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication and authorization only stay safe when the handoff between them is explicit. The article is right to treat the token or session as the boundary, not the endpoint. Many identity programmes document login well but under-specify the policy decision that follows, which is where real control failure begins. For practitioners, the governing question is whether every downstream action is evaluated against a separate access policy.

Broken access control is usually a sequencing failure, not a credential failure. Teams often look for weak passwords or missing MFA when the deeper issue is that authenticated identity was allowed to act without a policy decision. That matters across human IAM, NHI service accounts, and API-to-API trust because the failure mode is the same: identity proof without scoped authorisation. Practitioners should treat this as an application control design problem, not just an IAM configuration problem.

Authorization models are only useful when the identity layer produces clean claims. RBAC, ABAC, and ReBAC each depend on a trustworthy identity assertion coming from authentication. If claims are malformed, stale, or over-broad, the policy engine becomes a multiplier for bad identity data. That means IAM, IGA, and application teams need a shared contract for claims quality, not isolated control ownership.

Identity governance breaks down when access reviews assume policy is enforced somewhere else. Recertification can confirm that an identity should have access, but it cannot compensate for a code path that grants access without checking. This is why separation of concerns is not just software hygiene. It is the governance model that keeps human, machine, and workload identities from inheriting the same authorization defect at scale.

From our research:

• Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
• The average estimated time to remediate a leaked secret is 27 days, which shows how quickly identity and credential mistakes can become durable exposure.
• For broader NHI lifecycle context, The State of Secrets in AppSec is a useful companion to identity governance work because secrets handling and access control failures often overlap.

What this signals

Authorization discipline is becoming a programme-level control, not just a code review concern. Teams that treat access control as a back-end implementation detail will keep missing the trust boundary between verified identity and permitted action. That boundary matters just as much for service accounts and API tokens as it does for human login flows, which is why IAM, IGA, and appsec teams need a shared operating model.

The bigger signal is that identity governance now has to inspect whether policy is actually enforced, not simply whether access was assigned. If a valid identity can reach a sensitive action without a second decision, the programme has a control gap even if recertifications are clean. That is the kind of issue that survives audits and only appears under attack or misuse.

Policy evaluation at the edge of the request path is the design pattern to watch. As applications absorb more workload identity, federated access, and AI-connected interactions, the cost of a missed authorization check rises because more identities can act at machine speed without human review.

For practitioners

• Separate authentication from authorization services Keep credential validation, session issuance, and policy evaluation in different control paths so a login success never implies a permission grant. This makes it easier to test access logic independently and isolate failures before they reach production.
• Audit every protected endpoint for an explicit policy decision Inspect application routes, admin panels, and internal APIs to confirm each one calls an authorization check after identity verification. A valid session should never be treated as a sufficient condition for sensitive actions.
• Define the claim set that authorization is allowed to trust Document which identity claims, attributes, roles, or relationships each policy engine may consume, then validate that upstream authentication systems issue those claims consistently. This prevents policy drift caused by ambiguous or over-broad identity context.
• Test broken access control with negative-path scenarios Build test cases that use valid credentials but wrong roles, resources, or context so you can verify access is denied where it should be. This is the fastest way to expose places where authentication is doing authorization's job.

Key takeaways

• Authentication and authorization are distinct controls, and collapsing them creates broken access control.
• The dangerous failure is often not a failed login, but a missing policy decision after login succeeds.
• Identity teams should validate the trust handoff between verified identity and access policy across human, machine, and service contexts.

Key terms

• Authentication: Authentication is the process of proving that an identity is genuine. In practice, it uses credentials, certificates, biometrics, or other factors to establish who or what is requesting access. For NHIs, the key issue is whether the proof is strong enough to resist theft, replay, or misuse.
• Authorization: Authorization is the decision about what an authenticated identity is allowed to do. In NHI and IAM practice, it covers scope, duration, and allowable actions, and it is the layer that most directly controls blast radius when access is active.
• Broken Access Control: Broken access control occurs when a system fails to restrict what an authenticated user, service, or workload can do. The issue often appears as missing checks, inconsistent enforcement, or excessive permissions. It is a structural weakness because attacks exploit the gap between verified identity and permitted action.
• OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.

What's in the full article

Ory's full post covers the operational detail this post intentionally leaves for the source:

• Implementation patterns for separating login flows from policy enforcement in production systems
• Concrete examples of RBAC, ABAC, and ReBAC decisions across real application architectures
• The engineering rationale for keeping authentication and authorization as independently testable services
• Protocol-specific handling for sessions, tokens, and claims in modern IAM stacks

👉 Ory's full post covers the request lifecycle, control boundaries, and implementation patterns in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.