What is Identity Authentication?

Identity authentication is the process of checking evidence that a person requesting access to a digital account, service, or transaction controls an authenticator linked to that account. 

When someone returns to an online service, such as a banking app or customer account, a username or claim of identity alone is not enough. The system needs evidence that the person can legitimately use the account. Depending on the system, this evidence may include a password, one-time passcode, trusted device, passkey, or biometric check used with an appropriate authenticator. The aim of digital identity authentication is to establish confidence in the access attempt before granting access, rather than simply accepting a claimed username.

Identity verification vs authentication: What is the difference?

Identity verification and identity authentication are closely connected, but they serve different purposes. Identity verification establishes confidence in a person’s claimed identity, often during onboarding, while identity authentication confirms that someone accessing an existing account can prove they are the legitimate account holder. Understanding the difference between identity verification vs authentication helps businesses manage identity-related risk throughout the customer journey.

The distinction is useful, but it is not an absolute rule that verification happens only once, and authentication happens every time. Businesses may need to re-check identity information or repeat verification when circumstances change. Authentication may also be followed by session checks or reauthentication when risk increases.

How identity authentication works

The exact process depends on the service and the level of risk, but most digital authentication journeys follow a similar pattern:

The user identifies the account: The person enters an identifier, such as a username, email address, customer ID, or selects an account already known to the service.

The user presents an authenticator: They provide evidence linked to the account, for example, a password, a code from an authenticator app, a security key, or a passkey. In some flows, a biometric comparison helps activate an authenticator on the user’s device.

The system checks the evidence: The authentication service checks the submitted evidence using the relevant verification process. It may also consider signals such as device familiarity, location, or unusual activity as part of a risk assessment.

The system makes an access decision: If the authentication check succeeds and no additional control is required, the user can proceed. If the evidence fails or the attempt appears risky, access may be denied, or the system may request another check.

Access is limited to what the user is allowed to do: Authentication does not automatically grant permission to every feature or transaction. Authorisation rules determine what the authenticated user can access.

Some services also use step-up authentication. This means asking for stronger or additional evidence when a user attempts a sensitive action, signs in from an unfamiliar device, or triggers a risk signal. The aim is to apply checks in proportion to the situation rather than adding the same level of friction to every interaction.

Identity Authentication Methods

There is no single authentication method suited to every service. Businesses choose methods based on the sensitivity of the account, the likely threats, regulatory expectations, user experience, and the technology available.

Password and PIN authentication

Passwords and PINs are knowledge-based methods: the user proves knowledge of a secret associated with the account or authenticator. They remain familiar and widely supported, but passwords can be guessed, reused, stolen through phishing, or exposed in data breaches. Rate limiting, secure password storage, monitoring, and additional authentication controls help reduce these risks.

One-time passcodes (OTPs)

A one-time passcode is a short code intended for a single authentication attempt or a limited period. Codes may be generated by an authenticator app or delivered through a communication channel. Their security depends on how they are generated, delivered, and checked. SMS-based codes can be exposed to risks such as SIM swapping or interception, so the channel matters; email codes should not be treated as equivalent to every other OTP method.

Multi-factor authentication (MFA)

Multi-factor authentication combines at least two distinct factor types, such as something the user knows and something they have. Using two passwords does not create MFA because both are knowledge factors. Properly implemented MFA can make a stolen password less useful to an attacker, although the level of protection varies by method. Phishing-resistant options are especially valuable for higher-risk accounts and actions.

Biometric authentication

Biometric checks use characteristics such as a fingerprint or facial features. On many devices, a biometric comparison is used to unlock or activate a device-held authenticator rather than serving as a standalone secret. In remote identity journeys, biometric comparison and liveness detection may also help assess whether a person is present and whether a submitted face appears to be from a live person rather than a presentation attack. The role of biometrics depends on the system design: biometric identity verification and biometric authentication are related, but they are not automatically the same process.

Passkeys and cryptographic authentication

Passkeys use public-key cryptography to let a user authenticate without entering a traditional password. The service keeps a public key, while the corresponding private key is protected by the authenticator. During sign-in, the authenticator responds to a challenge in a way the service can verify. Passkeys are designed to resist phishing because authentication is tied to the legitimate service, although overall account security still depends on recovery processes, device security, and implementation.

Federated authentication and single sign-on (SSO)

With federated authentication, a service relies on a trusted identity provider to authenticate the user and communicate the result. Single sign-on allows users to access multiple connected applications through an established sign-in session. 

Risk-based and step-up authentication

Some systems assess signals such as device, network, location, session history, or an unusual transaction to decide whether more evidence is needed. These are contextual risk signals, not a separate universal authentication factor. Depending on the assessment, the service may allow the interaction to continue, request another factor, or block the attempt.

Where identity authentication is used

Identity authentication is used wherever a digital service needs to control access to an account, data, or action. The method and assurance required depend on what is at stake.

Banking, fintech, and payments: Protecting customer accounts, payment functions, transfers, and changes to sensitive account details. Higher-risk actions may trigger additional authentication.

E-commerce and online marketplaces: Securing customer and seller accounts, account changes, and sensitive activity that could expose payment details or enable fraud.

Healthcare: Controlling access to patient portals, appointment services, and sensitive health information while accounting for privacy and usability.

Gaming and digital platforms: Protecting user accounts against unauthorized access and account takeover.

Enterprise applications and SaaS: Managing employee access to cloud services, internal systems, and business data through MFA, SSO, or federated identity.

Travel, telecom, and on-demand services: Protecting accounts and selected high-risk actions, including account changes or reauthentication when a driver or worker begins a shift.

For businesses operating across sectors, authentication is not simply a login feature. It is one part of a wider identity and fraud-control strategy that may also include onboarding checks, transaction monitoring, account recovery safeguards, and ongoing risk assessment. Customer identity authentication should be designed around the account, transaction, and level of risk involved.

Identity Authentication Standards and Protocols

There is no single standard that governs every identity authentication system worldwide. Different standards and protocols address different parts of the process: some provide guidance on assurance and authenticator management, while others define how systems communicate or how credentials work.

NIST Digital Identity Guidelines: NIST SP 800-63-4 and its companion publications cover digital identity proofing, authentication and authenticator management, and federation. They describe authentication assurance levels that help organisations choose controls proportionate to the risk of a service. Read NIST SP 800-63-4

FIDO and W3C WebAuthn: FIDO standards and the Web Authentication (WebAuthn) specification support public-key-based authentication, including the technology used by passkeys. They help services implement authentication that can resist common credential-phishing attacks. Read the WebAuthn specification

OpenID Connect and SAML: These technologies support federated identity and single sign-on. OpenID Connect provides an identity layer over OAuth 2.0; SAML enables the exchange of authentication and related identity assertions between systems. They are protocols/technical specifications, not authentication factors. Read OpenID Connect Core

ISO/IEC 29115: This international standard addresses entity authentication assurance and provides a framework for considering how much confidence an authentication process provides. It is a different framework from NIST’s assurance levels. Read the ISO standard overview

The practical point is that standards should be selected in context. An organisation should consider the service being protected, the consequences of unauthorised access, the users’ needs, and any applicable legal or sector-specific requirements. A protocol or standard can support a secure design, but it does not by itself guarantee that an implementation is secure.

How Identity Verification and Authentication Work Together

Authentication is only as trustworthy as the account and authenticator relationship behind it. If an account was opened using a false or stolen identity, a later successful login does not make that original identity genuine. That is why businesses need to consider both identity checks at onboarding and controls that protect the account after registration.

Identity verification can help establish confidence in a customer’s identity when an account is created or when a new check is required. Authentication then helps protect subsequent access. Additional controls, such as liveness detection where appropriate, device signals, transaction monitoring, and secure account recovery, can help organisations respond when the risk changes. These controls serve different purposes and should be selected as part of a coherent risk-based journey.