"Authentication" and "authorization" get used interchangeably in casual conversation, but they answer two different questions, and conflating them is a common source of access-control mistakes. This article covers what authentication actually verifies, the three categories of authentication factors, and how authentication fits into the broader identity and access picture covered throughout this cluster.
Authentication vs. authorization
Authentication answers "who are you?" — it verifies that the entity requesting access is who it claims to be. Authorization answers "what are you allowed to do?" — it determines what an already-authenticated identity can access. A correctly authenticated user can still be authorized for very little; a system with strong authentication but weak authorization can still leak data to legitimate, verified users who simply shouldn't have had access to it.
Why this distinction matters practically
A password reset process is an authentication concern. A permission that lets a verified employee read a file outside their department is an authorization concern. Treating an authorization gap as if strengthening authentication would fix it — or vice versa — is a common, avoidable misdiagnosis in access reviews.
This cluster focuses on authentication — verifying identity — while role-based access provisioning and Operational Governance cover authorization more directly. In practice the two are implemented together (see Microsoft Entra Conditional Access, which evaluates both identity and context before granting access).
The three factor categories
Authentication factors fall into three categories, commonly summarized as "something you know, something you have, something you are."
| Category | Examples | Primary Weakness |
|---|---|---|
| Something you know | Password, PIN, security question | Can be phished, guessed, or reused across services |
| Something you have | Phone (authenticator app), hardware security key, smart card | Can be lost or stolen; SMS-based versions can be intercepted |
| Something you are | Fingerprint, face recognition, other biometrics | Cannot be changed if compromised; typically used to unlock a device-bound credential rather than transmitted directly |
Single-factor authentication relies on one category — almost always "something you know," typically a password. Multi-factor authentication (MFA) requires factors from at least two different categories. Two passwords are not MFA; a password plus an authenticator app code is, because they come from different categories.
Authentication method strength varies significantly
Not all authentication methods resist attack equally, and the categories above don't fully capture that variance — within "something you have," a hardware security key using FIDO2/WebAuthn resists phishing in a way a one-time code delivered by SMS does not, because the key cryptographically verifies the destination it's authenticating to, while a person reading a code aloud (or pasting it into a fake login page) has no such protection. See Multi-Factor Authentication: Methods and Best Practices for a full comparison, and Passwordless Authentication and Passkeys for the strongest currently available consumer/business methods.
MFA is not uniformly phishing-resistant
"We have MFA enabled" is not a single security posture — SMS codes, authenticator app codes, push notifications, and hardware keys have meaningfully different resistance to real-world attacks like adversary-in-the-middle phishing and MFA fatigue. See Authentication Attacks for how these attacks specifically target weaker MFA methods.
Identity as the foundation, not just login
Authentication is a single moment-in-time event — a login. Identity is the broader, ongoing concept: the lifecycle of an account from creation through role changes to eventual removal, and the ongoing question of whether an authenticated session should still be trusted. This is why modern identity platforms (Microsoft Entra ID, Okta, and similar) evaluate more than the login moment — Conditional Access re-evaluates context continuously, and Identity Governance manages the account's entire lifecycle. See Identity Lifecycle and Joiner-Mover-Leaver Governance for how this plays out operationally.
Why authentication strategy is a business decision, not just a technical one
Every authentication method sits on a curve between security and user friction — a hardware key is strong but has a real deployment and support cost; a password alone is frictionless but weak. Getting this trade-off right for a specific organization (which accounts need the strongest methods, which authentication events matter most) is the practical work this entire cluster addresses, starting from this foundational vocabulary.
Common mistakes
- Treating "we require a password" as an authentication strategy rather than a starting point that needs MFA layered on top — see NIST Password Guidelines for why password strength alone is treated as insufficient by current guidance.
- Assuming all MFA is equally strong. SMS-based MFA is significantly better than no MFA, but meaningfully weaker than an authenticator app or hardware key against a targeted attack.
- Conflating authentication fixes with authorization problems. Adding MFA does not fix an overly broad permission grant; it only makes it harder for an attacker to reach that permission in the first place.
- Applying the same authentication strength to every account. A standard user account and a global administrator account represent very different risk if compromised and typically warrant different authentication requirements — see Privileged Identity Management and Privileged Access.
FAQ
Is a password considered an authentication factor on its own? Yes — a password is a "something you know" factor. It is a valid single factor, but current guidance treats single-factor password authentication as insufficient for anything beyond low-risk access, precisely because that one category is the easiest to compromise at scale (phishing, credential stuffing, breach reuse).
What's the difference between authentication and identity verification (like a KYC check)? Identity verification (confirming a real-world identity, often during onboarding) and ongoing authentication (confirming that a login attempt is the same identity that was previously verified and provisioned) are related but distinct — this cluster's "authentication" scope covers the latter: verifying an already-provisioned account, not initial real-world identity proofing.
Do I need to understand SAML/OAuth/OIDC to understand authentication basics? No — those are federation protocols that let authentication happen once and be trusted across multiple applications, covered in Single Sign-On and Federation Explained. This article's factor-category model applies regardless of which protocol carries the authentication result.