Authentication is the process of verifying that a user, device, or system is who or what it claims to be. It happens by checking a credential, such as a password, a biometric scan, or a cryptographic key, against a record already held in an identity store.
What is authentication?
Authentication answers one question: is this the entity it claims to be? Nothing more. It doesn't decide what that entity is allowed to do, and it doesn't establish someone's real-world identity from scratch. It checks a presented credential against a stored reference and returns a yes or no. Every sign-in screen, every fingerprint scan, every one-time code you type into a phone is authentication doing its one job: confirming a match between a claim and a record. As NIST's identity and access management guidance frames it, the goal of IAM broadly is making sure the right people and things get the right access at the right time. Authentication is the first gate in that chain.
How authentication works
Authentication runs on credentials, and credentials fall into three factor categories: something you know (a password, a PIN), something you have (a phone, a hardware key, a registered device), and something you are (a fingerprint, a face scan, another biometric trait). A system checks the presented factor against what's stored in its identity store, and if it matches, it issues a session or token that lets the user move through the application without re-proving identity on every click. That session has a lifetime. It expires, it can be revoked, and it can be re-checked mid-session if risk signals change. This is the mechanical core of every authentication flow, whether it's a retail login, a bank app, or a machine calling an API on someone's behalf.
Authentication methods and factors
Not all authentication is equal, and the method matters as much as the fact that a check happened.
- Passwords. The oldest and weakest method on its own. Reused, guessed, phished, or leaked in a breach, a password is a single point of failure that carries no signal about who's actually typing it.
- One-time passcodes and MFA. Multi-factor authentication (MFA) combines two or more factor types, typically a password plus a code sent to a phone or generated by an app. Requiring a second factor closes most of the gap left by weak or stolen passwords, though SMS codes remain interceptable and shouldn't be the only second factor for sensitive accounts.
- Passkeys and biometrics. Passwordless authentication replaces the shared secret with a cryptographic key pair, unlocked locally by a fingerprint, face scan, or device PIN. The private key never leaves the device, so there's nothing centrally stored for an attacker to steal. This is standardized through WebAuthn, the W3C specification that defines how browsers and applications create and verify these public-key credentials. Read more on what passwordless login actually means and why Face ID is more secure than people assume.
- Social login and SSO. Letting a user authenticate once with an existing identity provider (Google, Apple, an enterprise IdP) and reuse that session across applications. Federation protocols like SAML and OpenID Connect define how the assertion of "this user authenticated successfully" gets passed between systems. See our breakdown of OIDC and why it matters for CIAM.
For a deeper look at where the industry is headed on credentials, see our piece on passkeys and passwordless authentication trends.
Authentication vs. authorization
This is the pairing people mix up most, and the confusion has real consequences. Authentication confirms identity. Authorization decides what that identity is permitted to do once confirmed. A user can authenticate successfully and still be denied access to a specific record, feature, or transaction because authorization is a separate decision made afterward.
| Authentication | Authorization | |
|---|---|---|
| Question answered | Is this who they claim to be | What is this identity allowed to do |
| When it happens | At login, or re-checked mid-session | After authentication, on every access request |
| What it produces | A verified session or identity token | A permission decision, often scoped to a resource |
| Common misuse | Treated as sufficient proof of trustworthy access | Assumed to be automatic once login succeeds |
If you want the fuller picture of where authentication sits inside the broader access stack, our explainer on the difference between CIAM and IAM covers how these pieces fit together at scale.
Authentication vs. identity verification
The second point of confusion is identity verification, and it's a timing difference as much as a functional one. Identity verification proves that a real person exists behind an identity claim, usually done once, at registration, by checking a government ID, running a liveness check, or cross-referencing data sources. Authentication happens every time that already-verified person returns and needs to prove they're the same person who registered.
| Authentication | Identity verification | |
|---|---|---|
| When it happens | Every sign-in, ongoing | Typically once, at account creation or a high-risk event |
| What it confirms | This credential matches a stored record | This person is a real, distinct individual |
| Typical inputs | Password, biometric, passkey, OTP | Government ID scan, liveness check, data source match |
| Common misuse | Assumed to prove real-world identity, which it doesn't | Repeated unnecessarily on every login, adding friction |
Skipping verification and relying on authentication alone means you can confirm someone knows a password without ever confirming a real person is behind that account in the first place. See how identity verification fits as a distinct capability from ongoing authentication.
Why authentication matters in CIAM
Authentication is where customer identity and access management (CIAM) shows up as a revenue and trust issue, not just a security control. Every added step at sign-in is a chance for a customer to abandon. Every weak method is a chance for account takeover. Modern CIAM handles this tension with adaptive, risk-based authentication: checking device, location, and behavior signals in real time and only stepping up to a stronger factor when risk actually warrants it, instead of forcing every user through the same friction every time. Our piece on how adaptive authentication improves sign-in journeys covers this in more detail, and adaptive access controls as a capability show what that looks like in practice.
Authentication is also expanding beyond human customers. AI agents acting on a customer's behalf need to authenticate too, and the same factor logic applies: an agent's identity has to be verified before it's trusted with any action. Governing that alongside customer and partner authentication is becoming part of what a CIAM platform is expected to do. For the fundamentals of the category this sits inside, see what CIAM is.
What to look for in a modern authentication solution
- Passwordless support. Native passkey and biometric support, not a bolt-on, so passwords can be phased out rather than merely supplemented.
- Adaptive, risk-based step-up. The ability to skip friction for low-risk sign-ins and demand stronger proof only when signals warrant it.
- MFA flexibility. Multiple second-factor options, not a single SMS-only path that becomes the weakest link.
- Orchestration control. The ability to design and change authentication journeys without a lengthy development cycle every time a policy shifts.
- Standards compliance. Support for WebAuthn, OIDC, and SAML so authentication interoperates with the identity providers and applications your customers already use.
For a practical look at what passwordless rollout actually involves, see what passwordless login really means.
Frequently asked questions
Is authentication the same as authorization?
No. Authentication confirms identity; authorization decides what that identity can do. A person can be authenticated and still denied access to a specific resource.
What counts as a valid authentication factor?
The three standard categories are something you know (a password), something you have (a device or security key), and something you are (a biometric).
Why does authentication design affect conversion, not just security?
Every extra step in a sign-in flow is a chance for a customer to abandon it, so CIAM systems tune authentication friction to the risk of the specific action rather than applying the same steps everywhere.
Is authentication the same as login?
Not exactly. Login is the user-facing action, the moment someone submits a credential. Authentication is the underlying process that checks that credential and decides whether it's valid. Login is the front door, authentication is the lock mechanism behind it.
What's the difference between authentication and authorization?
Authentication confirms who someone is. Authorization decides what they're allowed to do once that's confirmed. A verified login doesn't automatically grant access to every resource, that's a separate, ongoing decision.
Related terms
- Identity verification (adjacent)
- Authorization (adjacent)
- CIAM (above)
See also
Entries that come up in the same conversation as Authentication.
.avif)