Category: Identity and Access Management

Authentication

Also known as: AuthN, Identity Verification, User Authentication

Simply put

Authentication is the process of proving that a user, application, or device is who or what it claims to be, typically before granting access to a system or resource. It is distinct from identification, which merely states an identity without proving it. Common examples include entering a password, using a fingerprint scanner, or confirming a one-time code sent to your phone.

Formal definition

Authentication is the process of verifying the claimed identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system. It relies on one or more authentication factors, commonly categorized as something you know (e.g., passwords, PINs), something you have (e.g., hardware tokens, cryptographic keys), and something you are (e.g., biometrics). Multi-factor authentication (MFA) combines two or more of these factor categories to increase assurance. Authentication should be distinguished from authorization, which determines what an authenticated entity is permitted to do. In application security, robust authentication mechanisms are foundational controls, and weaknesses in authentication (such as credential stuffing vulnerabilities, session fixation, or insufficient credential complexity enforcement) represent a significant category of exploitable flaws.

Why it matters

Authentication is a foundational security control because it establishes trust at the boundary of every system interaction. Without reliable authentication, authorization controls become meaningless since there is no verified identity upon which to base access decisions. Weaknesses in authentication, such as credential stuffing vulnerabilities, session fixation, or insufficient credential complexity enforcement, represent a significant and frequently exploited category of application security flaws. Compromised authentication can lead to unauthorized access to sensitive data, privilege escalation, and lateral movement within systems.

The importance of authentication extends beyond individual user logins. In modern architectures, applications, services, and devices all require identity verification when communicating with each other. A failure in any of these authentication points can expose an entire system to compromise. The 2012 Dropbox breach, for example, stemmed from a reused employee password, illustrating how a single authentication weakness can cascade into the exposure of tens of millions of user credentials. Robust authentication practices, including multi-factor authentication and the enforcement of strong credential policies, are among the most effective controls organizations can adopt to reduce their attack surface.

Who it's relevant to

Application Developers

Developers are responsible for implementing authentication mechanisms correctly, including secure credential storage (e.g., using strong hashing algorithms), proper session management, and integration with authentication standards. Mistakes at the implementation level, such as failing to enforce credential complexity or mishandling session tokens, directly introduce exploitable vulnerabilities.

Security Engineers and Architects

Security professionals design authentication architectures that align with an organization's risk profile, selecting appropriate factor types, defining MFA requirements, and establishing policies for credential lifecycle management. They also evaluate authentication flows for weaknesses such as session fixation, token leakage, and replay attacks.

Identity and Access Management (IAM) Teams

IAM practitioners manage the operational aspects of authentication, including provisioning and deprovisioning credentials, configuring identity providers, and monitoring for authentication anomalies like credential stuffing attempts or brute-force attacks.

Compliance and Risk Officers

Authentication requirements are central to nearly every security compliance framework. These professionals must ensure that authentication controls meet regulatory and standards-based requirements, and they assess the risk implications of authentication weaknesses across the organization.

DevSecOps and Software Supply Chain Practitioners

In CI/CD pipelines and software supply chain contexts, authentication applies not only to human users but also to services, build systems, and automated processes. Ensuring that every entity in the pipeline is properly authenticated helps prevent supply chain attacks that exploit trust relationships between systems.

Inside AuthN

Identity Credentials

The evidence a user or system presents to prove identity, such as passwords, cryptographic keys, certificates, or biometric data.

Authentication Factors

Categories of proof used to verify identity, typically grouped as something you know (password, PIN), something you have (token, smart card), and something you are (fingerprint, facial recognition).

Multi-Factor Authentication (MFA)

A mechanism requiring two or more distinct authentication factors, reducing the risk of compromise from any single factor being stolen or guessed.

Authentication Protocols

Standardized methods for performing authentication exchanges, including SAML, OpenID Connect (which layers authentication on top of OAuth 2.0's authorization framework), and Kerberos.

Session Management

The process of maintaining authenticated state after initial verification, typically through session tokens or cookies, including controls for expiration, revocation, and binding.

Credential Storage

Secure handling and persistence of authentication secrets, including password hashing with adaptive algorithms (such as bcrypt, scrypt, or Argon2) and protection of key material at rest.

Common questions

Answers to the questions practitioners most commonly ask about AuthN.

Is authentication the same as authorization?

No. Authentication verifies the identity of a user, service, or system, establishing who or what is making a request. Authorization determines what that authenticated identity is permitted to do. Conflating the two often leads to security gaps where identity is verified but access controls are inadequately enforced, or where authorization checks are applied without reliable identity verification.

Is OAuth 2.0 an authentication protocol?

OAuth 2.0 is primarily an authorization framework, not an authentication protocol. It delegates access to resources without necessarily verifying end-user identity to the client application. OpenID Connect (OIDC), which is built on top of OAuth 2.0, adds a standardized authentication layer with ID tokens. Using OAuth 2.0 alone for authentication without OIDC or equivalent identity verification mechanisms can introduce security vulnerabilities, such as token misuse or confused deputy attacks.

When should multi-factor authentication (MFA) be required versus recommended?

MFA should typically be required for access to sensitive data, privileged operations, administrative interfaces, and systems handling regulated information such as financial or healthcare records. For lower-risk scenarios, MFA may be strongly recommended rather than mandated, though the threshold depends on organizational risk tolerance and applicable compliance requirements. In practice, enforcing MFA broadly reduces credential-stuffing and phishing risks, but implementers should account for usability impacts and recovery workflows.

How should authentication credentials be stored securely on the server side?

Passwords should be hashed using a memory-hard or computationally expensive algorithm such as Argon2, bcrypt, or scrypt, with a unique per-user salt. Plaintext or reversibly encrypted password storage must be avoided. For token-based or key-based authentication, secrets should be stored in dedicated secrets management systems rather than in application code or configuration files. The choice of hashing parameters (cost factor, memory, parallelism) should be tuned to balance security with acceptable response latency.

What are common pitfalls when implementing token-based authentication (e.g., JWTs)?

Common pitfalls include: failing to validate token signatures on every request, using weak or symmetric signing keys in contexts where asymmetric keys are appropriate, setting excessively long token expiration times, not implementing token revocation or rotation mechanisms, and storing sensitive data in unencrypted JWT payloads. Additionally, relying solely on client-side token validation without server-side checks can allow tampered or replayed tokens to be accepted in some configurations.

How should authentication failures be handled to avoid information leakage?

Authentication endpoints should return generic error messages that do not reveal whether the failure was due to an invalid username, an incorrect password, or a locked account. Timing differences between responses for valid and invalid usernames should be minimized, typically by performing the same hashing operation regardless of whether the account exists. Rate limiting, account lockout policies, and logging of failed attempts are recommended complementary controls, though account lockout thresholds should be calibrated to avoid denial-of-service conditions for legitimate users.

Common misconceptions

Authentication and authorization are the same thing.

Authentication verifies who a user or system is, while authorization determines what that verified identity is permitted to do. They are distinct steps in access control, though they are often implemented in close sequence.

OAuth 2.0 is an authentication protocol.

OAuth 2.0 is primarily an authorization framework that delegates access to resources. Authentication functionality is provided by OpenID Connect (OIDC), which is a layer built on top of OAuth 2.0 specifically designed for identity verification.

Adding multi-factor authentication eliminates all authentication-related risks.

MFA significantly raises the difficulty of credential compromise, but it does not eliminate risks such as session hijacking, real-time phishing proxies, MFA fatigue attacks, or vulnerabilities in the MFA implementation itself. Defense in depth remains necessary.

Best practices

Implement multi-factor authentication for all privileged accounts and, where feasible, for all user accounts, using phishing-resistant methods such as FIDO2/WebAuthn.

Store passwords using adaptive hashing algorithms (e.g., Argon2, bcrypt, or scrypt) with appropriate work factors, and never store credentials in plaintext or with reversible encryption.

Enforce account lockout or progressive throttling policies to mitigate brute-force and credential-stuffing attacks, while balancing usability to avoid denial-of-service conditions for legitimate users.

Use established authentication protocols and libraries rather than custom implementations, as custom schemes typically introduce subtle vulnerabilities that are difficult to detect through static analysis alone.

Bind authenticated sessions to contextual attributes where possible (such as client IP range or device fingerprint) and enforce session expiration, idle timeout, and secure token handling (e.g., HttpOnly, Secure, SameSite cookie flags).

Log and monitor authentication events, including failed attempts, credential resets, and MFA enrollment changes, to enable timely detection of account takeover attempts.