Authentication is the security process of verifying a claimed identity, confirming that a user, device or software service really is who or what it claims to be before a system grants access. In cybersecurity and identity and access management, it is the first gate of every access decision: the system first establishes who is asking and only then evaluates what that identity may do.
Authentication is distinct from two neighboring steps. Identification is the claim itself, such as entering a username, and authorization decides which resources the verified identity may use. Confusing these steps is a classic design error, because a perfectly authenticated user can still cause a breach when authorization is too broad.
Authentication factors and how they prove identity
Every authentication method relies on one or more authentication factors, which are categories of evidence that only the legitimate subject should be able to present. Using factors from two or more different categories is what defines multi-factor authentication (MFA); two passwords are still a single factor.
| Factor | Examples | Main strength | Main weakness |
|---|---|---|---|
| Knowledge | Password, PIN, security question | Cheap and universally supported | Can be guessed, reused, phished or leaked |
| Possession | Security key, smart card, phone with an authenticator app | Requires physical control of a device | Devices can be lost, stolen or cloned in weak implementations |
| Inherence | Fingerprint, face, voice | Convenient and always present | Cannot be changed if compromised; error rates vary |
Many systems add contextual signals such as device health, network location or typing behavior. These signals are not factors in the strict sense, but risk-based authentication uses them to request stronger proof, a technique called step-up authentication, when a login looks unusual.
Biometrics deserve a precise note. In modern devices, a fingerprint or face scan usually unlocks a cryptographic key stored on the device rather than being sent to a server. Biometric matching is probabilistic and is described by the false acceptance rate and the false rejection rate, which move in opposite directions as the matching threshold changes.
Common authentication methods compared
Authentication methods differ most in their resistance to phishing, which today is the decisive security property. A method is phishing-resistant when a fake website cannot collect anything that it could reuse against the real site.
| Method | Factor type | Phishing-resistant | Main risk |
|---|---|---|---|
| Password only | Knowledge | No | Reuse across sites and credential stuffing |
| SMS one-time code | Possession of a phone number | No | SIM swapping and interception |
| TOTP authenticator app | Possession of a shared secret | No | Codes can be relayed in real time |
| Push approval | Possession of a registered phone | No | MFA fatigue through repeated prompts |
| Smart card with PKI | Possession plus PIN | Yes | Complex issuance and lifecycle management |
| FIDO2 security key or passkey | Possession plus PIN or biometric | Yes | Account recovery becomes the weak point |
FIDO2 and passkeys resist phishing because the private key signs a challenge that is bound to the website’s origin, so a look-alike domain receives a signature it cannot use. Time-based one-time passwords defined in RFC 6238, by contrast, typically produce six digits every 30 seconds, and an adversary-in-the-middle proxy can forward such a code to the real site within that window.
Assurance levels and password guidance
Not every system needs the strongest method. The US guideline NIST SP 800-63B defines three authenticator assurance levels (AAL) that match the strength of authentication to the risk of the transaction.
| Level | Requirement | Typical use |
|---|---|---|
| AAL1 | Single-factor or multi-factor authentication | Low-risk services with limited personal data |
| AAL2 | Two distinct factors with approved cryptographic protection | Most business, financial and personal-data systems |
| AAL3 | Hardware-based, phishing-resistant authenticator with a non-exportable key | Privileged administrators and high-value systems |
For passwords, current NIST guidance favors length over complexity rules, screening new passwords against lists of breached and common passwords, and no forced periodic changes unless compromise is suspected. On the server side, passwords must never be stored in plain text; they are protected with salted, deliberately slow hashing such as Argon2id, scrypt, bcrypt or PBKDF2, so that a stolen database resists offline cracking.
Authentication protocols and federation
In networks and distributed applications, authentication is carried out by standardized protocols that let one trusted system verify an identity and pass the result to others. This is the foundation of single sign-on (SSO), where a user authenticates once with an identity provider and accesses many applications.
| Protocol | Typical environment | What it conveys |
|---|---|---|
| Kerberos | Active Directory and enterprise networks | Time-limited tickets issued by a key distribution center |
| SAML 2.0 | Enterprise web SSO | Signed XML assertions about the authenticated user |
| OpenID Connect | Modern web and mobile applications | Signed ID tokens built on top of OAuth 2.0 |
| RADIUS | VPN, Wi-Fi and network devices | Accept or reject decisions from a central server |
| Mutual TLS | Service-to-service and device communication | Proof of possession of a private key matching a certificate |
A frequent misconception is that OAuth 2.0 is an authentication protocol. It is an authorization framework for delegating access to resources; OpenID Connect adds the identity layer that makes it suitable for login. Machine identities follow the same logic, and workload authentication with short-lived certificates or tokens is replacing static API keys in cloud environments.
Attacks on authentication and their countermeasures
Attackers increasingly bypass authentication instead of breaking it, for example by stealing a session cookie issued after a successful login. Protection therefore has to cover the whole session, not only the moment of sign-in.
| Attack | How it works | Effective defense |
|---|---|---|
| Credential stuffing | Leaked username and password pairs are tested at scale | MFA, breached-password screening and rate limiting |
| Adversary-in-the-middle phishing | A proxy relays the login and captures the session | Phishing-resistant FIDO2 authentication |
| MFA fatigue | Repeated push prompts until the user approves | Number matching and limits on prompts |
| Session token theft | Malware copies cookies after login | Short session lifetimes and token binding to the device |
| Help desk social engineering | An attacker convinces support to reset MFA | Strict identity verification for recovery |
The weakest link is often account recovery. A system protected by security keys but recoverable through an email link or a phone call is only as strong as that recovery path, so recovery procedures must meet the same assurance level as the primary method.
A non-technical view
Authentication is how a computer system checks that someone is really who they say they are. Typing a username is only a claim; the password, the code from a phone or the fingerprint is the proof.
It works like showing an ID card at a building entrance. The guard first checks that the card is genuine and belongs to the visitor. Only after that does the guard decide which floors the visitor may enter, which is a separate step. Stronger proof, such as a physical security key, makes it much harder for an impostor to get in.
A concrete example
A manufacturing company with 2,500 employees uses passwords plus push notifications for its cloud email and VPN. After an adversary-in-the-middle phishing campaign captures the session cookies of three employees, the security team decides to move to phishing-resistant authentication.
Over six months, the company issues FIDO2 security keys to 180 administrators and enables passkeys on managed laptops and phones for all other staff. Conditional access rules require a compliant device and a FIDO2 credential for administrative portals, and account recovery now requires an in-person or video identity check. In the following year, internal phishing simulations still lure some employees to fake login pages, but none of those visits produces a usable credential or session, because the keys refuse to sign for the wrong domain.