# Authentication vs. Authorization: Understanding the Difference
Authentication and authorization are the two foundational controls that determine who gets into a system and what they can do once inside. Despite being distinct operations, they are routinely conflated in architecture reviews, incident post-mortems, and even vendor documentation. The confusion is not merely semantic. When teams treat these as interchangeable, they build systems where a stolen credential grants unlimited access, or where a verified user cannot reach the resources their job requires. Understanding the precise boundary between these two controls, and designing systems that enforce both independently, is a prerequisite for building any access control architecture that holds up under real-world conditions.
---
Authentication is the process of verifying that an entity is who or what it claims to be. The entity presents evidence, commonly called credentials, and the system checks that evidence against a stored representation of the claimed identity. If the evidence matches, the entity is authenticated. If it does not, access is denied before any resource decision is made.
Authorization is the process of determining whether an authenticated entity is permitted to perform a requested action on a specific resource. Authorization is always a second step. It cannot occur meaningfully without a preceding authentication event, because the access control policy needs a verified identity to evaluate against.
These two concepts are distinct from each other and from adjacent concepts:
Identity is the persistent record of who or what an entity is within a system. Authentication is the act of verifying that record at a specific moment in time.
Access control is the broader discipline that encompasses both authentication and authorization, along with audit logging, session management, and privilege management.
Accountability is the ability to trace actions back to a specific authenticated identity. It depends on authentication being accurate, but it is not the same as authentication.
Authentication is not access control by itself. A system that verifies identity but applies no authorization policy effectively treats all authenticated users as equivalent, which violates the principle of least privilege. Authorization without authentication is equally broken: if identity is not verified, authorization decisions are based on unconfirmed claims and can be trivially spoofed.
Variants and subtypes matter here. Authentication can be single-factor, multi-factor, or continuous. Authorization models include role-based access control (RBAC), attribute-based access control (ABAC), mandatory access control (MAC), discretionary access control (DAC), and policy-based access control (PBAC). Each model applies authorization logic at different levels of granularity.
---
Authentication begins when a subject, such as a user, a service account, or a device, asserts an identity to a system. The system, acting as a verifier, requests proof. The subject presents credentials. The verifier checks those credentials against an authoritative source, such as a directory service, an identity provider, or a local credential store. If the credentials are valid, the verifier issues a token, session identifier, or certificate that represents the authenticated session going forward.
The three classical authentication factors are:
Multi-factor authentication (MFA) combines at least two of these factors. An attacker who steals a password still cannot authenticate without the second factor. This is why MFA reduces the risk of credential-based compromise so substantially.
Modern authentication increasingly uses federated identity protocols. In a federated model, a central identity provider (IdP) such as Okta, Microsoft Entra ID, or a SAML-compliant service handles authentication on behalf of multiple relying party applications. The application never sees the user's password. Instead, the IdP issues a signed assertion confirming the user's identity. The application trusts the assertion because it trusts the IdP. This architecture separates authentication logic from application logic, which reduces attack surface and simplifies auditing.
Once authentication succeeds, the system has a verified identity. Authorization then evaluates that identity against an access control policy to answer: is this identity permitted to perform this action on this resource?
In role-based access control (RBAC), the system checks what roles the authenticated user holds and what permissions those roles carry. A user in the "finance-read-only" role can view financial records but cannot modify them. A user in the "finance-admin" role can modify them. The authorization engine checks role membership before allowing the request to proceed.
In attribute-based access control (ABAC), the decision is more granular. The authorization engine evaluates multiple attributes simultaneously: the user's department, their clearance level, the classification of the resource, the time of day, the network location of the request, and the specific action being requested. ABAC can enforce rules like "allow access to patient records only if the requester is a licensed clinician, is accessing records for a patient currently assigned to their care unit, and is operating from an approved clinical workstation." This level of contextual control is not achievable with simple role assignments.
Consider a hospital information system. A nurse logs in using their employee credentials and a hardware token. The identity provider verifies both factors and issues a session token. That is authentication: the system now knows with high confidence that this is a specific, verified nurse.
The session token is passed to the electronic health record (EHR) application. The application queries the authorization service: can this nurse read patient records in Ward 4? The authorization service checks: the nurse is in the "ward-4-clinical-staff" role, the request is for read access, the requested records belong to patients in Ward 4, and the access is occurring during normal shift hours. All conditions pass. Access is granted.
Now suppose the same nurse attempts to access the pharmacy dispensing controls. The authorization service checks: the nurse does not hold the "pharmacy-staff" or "pharmacist" role. Access is denied. The nurse's identity is not in question. The denial is an authorization decision, not an authentication failure.
This distinction matters operationally. If the system logs this event as an "authentication failure," investigators will waste time looking for credential problems that do not exist. Proper logging must distinguish between the two event types.
---
Conflating authentication and authorization produces specific, documented failure modes. The most common is the assumption that a successfully authenticated user should have broad or unrestricted access. This assumption has contributed to some of the most costly breaches on record.
The 2020 SolarWinds supply chain compromise illustrated what happens when authentication succeeds but authorization policies are insufficiently granular. Once attackers obtained valid credentials or tokens through the compromised build pipeline, those credentials carried extensive permissions across target environments. Authentication was working as designed. Authorization policies were too permissive, failed to apply least privilege, and did not detect lateral movement because the activity appeared to come from authenticated identities.
The 2021 Microsoft Exchange Server compromises (Hafnium and related threat actors) involved authentication bypasses that then allowed attackers to write web shells and execute commands. When authentication controls can be bypassed, authorization policies downstream become irrelevant because the authorization engine is evaluating a spoofed or fabricated identity.
A persistent misconception is that MFA solves the authorization problem. It does not. MFA strengthens authentication. It does nothing to constrain what an authenticated user can do. An attacker who successfully bypasses MFA through session hijacking, adversary-in-the-middle proxy attacks, or SIM swapping now has an authenticated session and is subject only to whatever authorization controls exist. If those controls are weak, the attacker has broad access despite the MFA being in place.
Another misconception is that authorization is a feature to configure once and forget. Authorization policies drift. Users accumulate roles over time through job changes and project assignments without old permissions being revoked. This is called privilege creep, and it results in users holding far more access than their current role requires. Regular access reviews and automated de-provisioning are operational requirements, not optional hygiene.
Organizations that do not separate authentication and authorization at the architectural level also struggle with incident response. When a breach occurs, investigators need to determine exactly what an attacker accessed. If the access control system does not maintain distinct, queryable logs for authentication events and authorization decisions, reconstructing the blast radius of a compromise is significantly harder and slower.
---
The Planetary Defense Model (PDM) treats authentication and authorization as distinct enforcement layers within the Identity, Authentication, and Trust (IAT) domain. CDA's approach is grounded in Zero Possession Architecture (ZPA), which holds that no actor, human or machine, should possess standing credentials or persistent permissions. Trust is not assumed from prior authentication. It is verified continuously at each access request.
Under ZPA, authentication is event-driven and ephemeral. Rather than issuing long-lived session tokens that carry authority across an entire workday, CDA's IAT methodology advocates for short-lived, cryptographically bound assertions that expire within minutes and must be re-verified at meaningful decision points. This reduces the window during which a compromised token can be used and forces re-evaluation of authorization conditions at each sensitive operation.
For authorization, ZPA applies a policy-as-code approach. Authorization rules are not configured through graphical interfaces and stored in opaque databases. They are written as auditable code, version-controlled, and tested against defined scenarios before deployment. This makes authorization policy changes traceable, reviewable, and reversible.
CDA's IAT methodology also mandates separation of the authentication plane from the authorization plane at the infrastructure level. The identity provider handles authentication. A separate policy decision point (PDP), implementing ABAC or PBAC, handles authorization. Applications never make their own authorization decisions. They query the PDP and enforce the response. This separation means that a compromise of the application layer does not automatically compromise the authorization logic.
Operationally, CDA treats any authentication event without a corresponding, logged authorization decision as an incomplete control. Both events must be captured, correlated, and reviewable. In the PDM framework, the absence of either log type is treated as a control gap requiring immediate remediation.
ZPA's principle of "Trust nothing. Possess nothing. Verify everything." applies directly here: authentication verifies identity at a moment in time, authorization verifies the right to act at that same moment, and neither grants standing trust for future requests.
---
---
---