Understanding Authentication as a System

What is authentication?

Authentication is often summarized as proving that a user is who they claim to be. That is a useful starting point, but real authentication systems are more precise—and more complicated—than that sentence suggests.

In a digital system, authentication usually asks whether a person, device, or process can demonstrate control of an authenticator that has already been associated with an account or identity. That authenticator might be a password, a security key, a registered phone, a cryptographic credential such as a passkey, or another approved mechanism.

This distinction matters because authentication is not the same as establishing a person’s real-world identity. A website may successfully authenticate the owner of an account without knowing who that person is outside the service.

Identification, authentication, and authorization are different

Three concepts are often mixed together:

Identification answers: Which account or identity is being claimed?

A username, email address, account number, or other identifier can tell the system which identity the user wants to act as.

Authentication answers: Can the claimant demonstrate that they are entitled to use that identity?

This is where passwords, one-time codes, security keys, biometrics, passkeys, and other authenticators enter the process.

Authorization answers: What is the authenticated identity allowed to do?

A user may successfully authenticate and still be unable to access a particular file, administrative function, or transaction.

A secure system must handle all three correctly. Strong authentication does not compensate for broken authorization, and knowing an account identifier does not authenticate its owner.

What can be used to authenticate?

Authentication mechanisms are commonly discussed in terms of factors.

A knowledge factor is based on something the user knows, such as a password or PIN.

A possession factor is based on something the user controls or possesses, such as a registered phone, hardware token, or security key.

An inherence factor is based on a characteristic of the user, such as a fingerprint or another biometric.

Modern systems can also rely on cryptographic authenticators whose private keys are protected by a device and may require local user verification before use. Passkeys are an important example.

The categories are useful, but the factor label alone does not tell us whether a system is secure. Two mechanisms can both be described as possession factors while providing very different resistance to phishing, relay, malware, device theft, or recovery abuse.

This is one reason authentication should be evaluated as a system, not only as a factor.

Authentication extends beyond the login screen

In practice, authentication begins before a user signs in.

An account may first need to enroll a password, register a phone, create a passkey, or bind another authenticator. Later, the user signs in, responds to additional challenges, adds or removes devices, changes credentials, and may eventually need to recover access when the normal path fails.

Each stage can change the system’s security.

A strong authenticator can be weakened by insecure enrollment. A carefully protected account can be undermined by an overly permissive recovery process. A second factor can stop an attacker who knows the password, yet still depend on the user correctly interpreting an approval request.

Our ACM Computing Surveys analysis of password managers and two-factor authentication reinforces this broader perspective. Different mechanisms provide different tradeoffs across security, usability, deployability, and privacy. No single approach performs best across every property.

That observation is important beyond passwords and 2FA: authentication design is usually a question of which properties a system provides, under which threat model, and at what cost to users and deployment.

Authentication can require a security decision

Some authenticators ask the user only to prove possession or knowledge. Others ask the user to make a judgment.

Push-based multi-factor authentication is a useful example.

A typical flow may look simple:

1. The user starts a sign-in attempt.
2. The service sends a request to a registered device.
3. The user reviews the request.
4. The user approves or rejects it.
5. The service proceeds if the required approval is valid.

The protocol may execute exactly as designed while the user still makes the wrong decision.

If an attacker can trigger a request that appears plausible, the system may correctly process an approval that the user should never have given.

Our study of push-based compare-and-confirm authentication illustrates this boundary. In benign trials, participants completed legitimate authentication with true-positive rates above 95%. Under fraudulent trials, however, participants correctly identified only about half of the attack attempts.

The mechanism could complete the authentication transaction correctly.

The human security decision could still fail.

Compare-and-confirm—often called number matching—improves on simple push approval by requiring the user to match information associated with the sign-in request rather than merely tapping an Approve button.

That additional step helps bind the approval to a particular request. But our results show that adding a comparison step does not automatically eliminate false approvals. Attention, interface design, timing, and the information shown to the user still matter.

Usability is part of the security model

Usability is sometimes treated as a secondary concern: first make the authentication mechanism secure, then make it convenient.

For systems that depend on human action, that separation is misleading.

Users are part of the execution path. They interpret prompts. They switch between devices and applications. They compare information. They respond to warnings. They decide whether an event looks expected or suspicious.

Repeated or poorly designed prompts can also produce habituation. In push authentication, for example, repeated requests can encourage reflexive approval rather than deliberate verification.

But the relationship between usability and security is not simply “less friction is better” or “more friction is safer.”

Our later study, The Mobile Paradox, examined compare-and-confirm under different device contexts. The results did not show a uniform mobile penalty. Medium-skill participants were more likely to reject attack attempts correctly on phones than on PCs, while high-skill participants showed little device difference.

The important lesson is not that mobile friction is always beneficial. It is that interaction design can change security behavior.

Friction is useful only when it directs attention toward the security-relevant decision.

Removing every step may make authentication faster while also removing useful opportunities to verify what is happening. Adding unnecessary steps can create fatigue without adding meaningful protection.

The objective is therefore not minimum interaction.

It is the right interaction at the right moment.

Context and binding matter

Authentication is also about what a credential or approval is bound to.

Consider number matching again. A number displayed on two screens can help connect a push notification to a specific authentication request. But the number alone may not tell the user:

• which service initiated the request,
• which account is being accessed,
• which browser or device will receive the resulting session,
• where the request originated,
• or whether the request is consistent with what the user is currently doing.

That distinction becomes important when attackers can create legitimate-looking authentication requests but attempt to redirect the resulting access.

In Hardening Push MFA: A Standards-Based Context Architecture for Number Matching, we examine how number matching can be strengthened with clearer request and relying-party context.

The principle is broader than push MFA:

A user should understand what is being authorized, not merely how to authorize it.

Authentication therefore needs meaningful binding between the authenticator, the request being approved, the service involved, and—where relevant—the session or transaction that follows.

Five questions for evaluating an authentication system

A useful evaluation starts with five questions.

1. What is being proved?

Is the system verifying knowledge of a secret, possession of a device, control of a cryptographic key, a biometric characteristic, or a combination of these?

2. What is the authentication bound to?

Does the proof or approval clearly correspond to the intended account, service, device, browser session, or transaction?

3. What decision does the user have to make?

Is the user simply completing an action, or is the system expecting the user to recognize whether something is suspicious?

That difference matters. A design that relies on user judgment must provide enough information for that judgment to be realistic.

4. What happens when the normal path fails?

How are credentials reset? How is a lost device replaced? How is a new authenticator enrolled? Can the recovery path bypass protections that are strong during normal sign-in?

5. What must an attacker defeat?

A realistic threat model should consider more than the authenticator itself. An attacker may target the protocol, the interface, the user, the device, enrollment, recovery, or the session created after authentication.

These questions move the discussion away from:

“Is this authentication method secure?”

toward a more useful question:

“Under what conditions does this authentication system remain secure?”

Authentication is a system

Authentication is not a password.

It is not an OTP.

It is not a push notification, biometric scan, security key, or passkey.

Those are components.

The authentication system includes identities, authenticators, devices, protocols, interfaces, user decisions, request context, lifecycle operations, recovery paths, and the access established after authentication.

Understanding how those pieces interact is the foundation for evaluating authentication in the real world.

And the most familiar place to begin is the oldest and still most widely used knowledge factor: the password.

The next article examines how password authentication works, why passwords remain so common, where their security limitations come from, and why password security has to be considered as part of a larger authentication system.

References

1. An In-Depth Analysis of Password Managers and Two-Factor Authentication Tools
2. Usability and Security Analysis of the Compare-and-Confirm Method in Mobile Push-Based Two-Factor Authentication
3. The Mobile Paradox: How Interface Friction Can Improve 2FA Security
4. Hardening Push MFA: A Standards-Based Context Architecture for Number Matching

Discussion & Questions

Continue the conversation.

Have a question, a different perspective, or practical experience related to this topic? I welcome thoughtful discussion around the ideas and evidence presented in this article.

Connect on LinkedIn↗Contact me→