Authentication
Authentication is the process of confirming that someone is who they previously established themselves to be. It compares a presented credential against an enrolled reference and returns a yes or no. It is routinely confused with identification, which asks a harder question — not is this the same person as before, but who is this person — and the confusion causes real design mistakes.
| What it establishes | That the presenter matches an enrolled reference |
| What it presumes | That enrollment already happened and was correct |
| Factor categories | Knowledge, possession, inherence |
| Comparison type | One-to-one against a specific claimed identity |
| Distinct from identification | Identification is one-to-many, against a population |
| Distinct from authorization | Authorization decides what an authenticated party may do |
| Distinct from verification | Identity verification establishes who someone is at first contact |
| Fails silently when | The enrolled reference belongs to the wrong person |
Authentication, identification, verification, authorization
Four words used interchangeably in conversation and meaning four different things in a system design.
| Term | Question | Comparison |
|---|---|---|
| Identity verification | Who is this person? | A claimed identity against authoritative evidence — a government document, a biometric |
| Identification | Which of these people is this? | One-to-many, against a population |
| Authentication | Is this the same person as before? | One-to-one, against an enrolled reference |
| Authorization | What is this person allowed to do? | An authenticated identity against a permission model |
The order matters and is frequently inverted in practice. Verification happens once, at the beginning, and establishes the reference. Authentication happens repeatedly afterwards, against that reference. Authorization happens after authentication. An error at the first step propagates silently through every step after it, because each later step is doing its job correctly with respect to a reference that was wrong from the start.
How it works
Every authentication is the same shape: a claim, a credential, and a comparison. The user claims an identity, presents evidence, and the system compares that evidence against what it holds. What varies is the evidence.
Knowledge factors are shared secrets — passwords, PINs, security answers. Their weakness is structural: the verifier must know the secret to check it, which means it can be stolen from the verifier as well as from the user.
Possession factors prove control of a device or key. Modern forms avoid the shared-secret problem by having the device sign a challenge with a private key that never leaves it, so nothing reusable crosses the wire.
Inherence factors compare a biometric against a stored template. On consumer devices the biometric usually never leaves the hardware — a successful local match releases a private key, and the server sees a signature rather than a face. That distinction matters for both privacy and security, and it is widely misunderstood.
Why authentication matters for identity verification
The relationship is one of dependency, and stating it precisely is the point of this page. Authentication inherits whatever identity verification established. A system authenticating against a reference created by a fraudster will authenticate the fraudster perfectly, forever, and every log will show a clean record.
Two practical consequences follow. First, enrollment deserves more scrutiny than any subsequent sign-in, because it is the only moment when the identity itself is in question — and it is routinely the least-defended step in the flow. Second, account recovery is a second enrollment. When someone loses every factor, the system must re-establish identity from scratch, and doing that with knowledge-based authentication means relying on data that breaches have made public.
This is why document and biometric checks have moved into recovery flows rather than staying at onboarding. Comparing a live face against a government-issued document re-establishes identity against evidence an attacker cannot look up. Identity document verification is what makes the reference trustworthy in the first place, and identity verification at enrollment is what every later authentication quietly depends on.
What authentication can’t do
It cannot establish identity. It confirms a match against a reference. Whether the reference belongs to a real, correctly identified person is a different question, answered earlier or not at all.
It cannot detect a compromised enrollment. Nothing about a successful authentication signals that the enrolled reference was fraudulent.
It does not survive session theft. Once a session exists, subsequent requests are trusted without re-authenticating.
It does not decide permissions. Authorization is a separate layer, and treating a successful authentication as sufficient for access is a recurring design error.
Frequently asked questions
What is the difference between authentication and identity verification?
Identity verification establishes who someone is at first contact, using authoritative evidence such as a government document and a biometric comparison. Authentication confirms on later visits that the same person has returned, by comparing a credential against the reference enrollment created. Verification happens once; authentication happens repeatedly.
What is the difference between authentication and authorization?
Authentication establishes who someone is with respect to an enrolled identity. Authorization determines what that identity is permitted to do. A correctly authenticated user may still be denied access to a resource, and treating authentication as sufficient for access is a common design error.
Is biometric authentication more secure than a password?
It removes the shared-secret problem — there is nothing for a verifier to store that an attacker can steal and reuse elsewhere. But a biometric cannot be reissued if compromised, and its security depends heavily on whether the match happens on a trusted device and whether presentation attack detection is present.
Can authentication detect a fraudulent account?
No. If the account was opened by a fraudster, that fraudster is the legitimate enrollee and every authentication will correctly succeed. Fraudulent accounts are identified at enrollment, or later through behavioral signals, not through the authentication step.
Related reading
- Multi-factor authentication — combining factor categories, and why phishing resistance matters more than factor count
- Biometric authentication — the inherence factor, and what actually crosses the network
- Identity document verification — the step that establishes the reference authentication depends on
- Getting remote identity verification right — why the enrollment step carries the weight in the whole flow