Authentication verifies the identity of a user (or, in machine-to-machine scenarios, a client or service) before they can access a protected resource. It answers the fundamental question: “Who are you?”

Before any application grants access, it must confirm that the requesting entity is who it claims to be. Authentication is the first step in access control and always precedes authorization. You must verify an identity before determining what that identity is allowed to access.

Users and services prove their identity by presenting credentials or verification factors that the system validates against stored records or a trusted external Identity Provider (IdP). Think of it like a developer presenting a Secure Shell (SSH) key to a remote server; the server verifies the key’s signature to confirm the client’s identity.

Why it matters: Authentication establishes identity before granting access. Without a verified identity, your application can’t enforce authorization policies, protect sensitive data, or maintain audit trails.

Authentication factors are classified into three distinct categories. The inherent security strength of Multi-Factor Authentication (MFA) comes from combining factors from two or more different categories.

Factor Category	Proof Mechanism	Common Example
Knowledge (Something you know)	A secret memorized by the user	Password, Personal Identification Number (PIN), Passphrase
Possession (Something you have)	A physical device or token under the user’s control	Smartphone (for TOTP/Push), hardware security key, FIDO2/WebAuthn key, Smart Card
Inherence (Something you are)	A unique, verifiable biological trait	Fingerprint, Facial recognition, Iris scan

Beyond basic passwords, there are several authentication methods, each with different security and usability trade-offs.

Password-Based Authentication

Password-based authentication is the most common method. Users provide credentials, which are checked against securely stored records.

Secure password storage requires adaptive, computationally expensive hashing algorithms like Argon2, bcrypt, or PBKDF2, always with unique salts for each password (NIST SP 800-63B). Never use legacy algorithms like MD5 or SHA-1.

Password vulnerabilities:

• Phishing and malware steal passwords directly
• Password reuse across sites allows one breach to compromise multiple accounts
• Weak passwords that users pick because they’re easy to remember
• Credential stuffing uses leaked password lists from previous breaches

Password-only authentication isn’t enough for production systems.

Multi-Factor Authentication

MFA requires users to verify identity using two or more distinct factors from different categories before access is granted.

After entering a password, users must provide a second factor, like a code from an authenticator app, a push notification confirmation, or a biometric scan. This blocks most credential theft attacks because attackers need both factors. SMS and email codes are weaker than push notifications or FIDO2 hardware authenticators.

Passkeys (FIDO2/WebAuthn)

Passkeys replace passwords with FIDO2 credentials that are phishing-resistant by design. They’re built on the FIDO2 protocol (WebAuthn and CTAP).

Passkeys use public-key cryptography. During enrollment, the device generates a public/private key pair. The private key is cryptographically bound to the device and designed to be non-exportable from the device’s secure enclave. The public key registers with the service, proving the device’s authenticity.

When logging in, the device signs a cryptographic challenge. This signature works only for the specific domain that requested it. A phishing site can’t intercept and reuse the signature, even with real-time phishing proxies. Passkeys offer phishing-resistant, MFA-grade security because the private key never leaves the device and is unlocked through biometrics or a device PIN. They can sync across devices via platform credential managers (e.g., iCloud Keychain), unless policies require them to remain device-bound.

Federated Identity and Social Login

Federated identity delegates authentication to a trusted external IdP.

OpenID Connect (OIDC): Users authenticate with the IdP. The application receives a cryptographically signed ID Token containing verified identity claims (email, name) without handling the user’s credentials.

This eliminates the need for credential storage, reduces onboarding friction, and lets the application leverage the IdP’s security infrastructure. In enterprise environments, SAML 2.0 is also common for Single Sign-On (SSO).

Single Sign-On

SSO enables users to authenticate once with a central IdP and then gain access to multiple applications without re-entering credentials.

SSO uses protocols like SAML 2.0 or OpenID Connect. The IdP issues a security token after the user logs in and maintains the session. Apps trust that session for access without requiring new logins. Many organizations align SSO session lifetimes with typical workday patterns. Actual durations depend on security policies, risk signals, and assurance requirements.

Modern authentication uses a dedicated Authorization Server or IdP that issues standards-based tokens for access.

OpenID Connect (OIDC) and OAuth 2.0

Understanding the difference:

OAuth 2.0 is an authorization framework designed solely for access delegation. It lacks a standardized token or protocol for verifying the end-user’s identity.

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. OIDC provides a standardized way for clients to verify user identity using an ID Token, which contains signed authentication claims from the IdP.

They work together: OIDC handles authentication (proving identity), and OAuth 2.0 handles authorization (granting API access).

The Authorization Code Flow with PKCE

The Authorization Code Flow with Proof Key for Code Exchange (PKCE) is the recommended flow for web and mobile applications. PKCE prevents authorization code interception attacks.

How it works: The app generates a high-entropy code verifier and a hashed code challenge. The user authenticates with the Authorization Server. The server issues a short-lived authorization code (expires in minutes). The server checks that the verifier matches the challenge before issuing tokens.

The server issues an ID Token containing authentication claims for the client, and an Access Token for calling APIs. When the application requests offline access (through the offline_access scope), the server issues a Refresh Token that can be used to renew access tokens without re-authentication.

Token-Based Authentication and JWTs

APIs don’t authenticate users directly. They validate tokens. This approach makes authentication stateless and scalable because the API doesn’t need to maintain session information in a database.

JSON Web Tokens (JWTs) are the most common token format. JWTs enable stateless API validation because all required claims are contained within the token. Some architectures remain fully stateless, while others optionally perform additional checks (e.g., user status or token revocation) depending on security requirements.

When a client calls the API, it includes the access token in the Authorization: Bearer <token> header. The API must validate the JWT on every request to ensure it is authentic, unexpired, and intended for the application:

• Verify the token structure conforms to JWT format `header.payload.signature`
• Check signatureusing the appropriate key to ensure the token hasn't been tampered with
• Verify expiration (exp) and optionally nbf (not before) and iat (issued at) claims to reject invalid or premature tokens
• Confirm the issuer (iss) matches your trusted IdP
• Verify the audience (aud) matches your application
• Prefer asymmetric signing algorithms (RS256 or ES256) so the API validates tokens using a public key without storing shared secrets.; use HS256 only in fully trusted environments
• Never accept the none algorithm, as it bypasses signature verification

APIs, services, and machine-to-machine communication require cryptographic identity verification that doesn’t rely on human interaction.

Client Credentials Flow: The OAuth 2.0 flow for server-to-server communication. The service authenticates using its client_id and client_secret (which must be protected as sensitive credentials and never committed to version control). After validating the credentials, the Authorization Server issues an Access Token.

Asymmetric Key Pairs: Services can use asymmetric key pairs to authenticate clients through a signed JWT assertion (RFC 7523). The Authorization Server validates the signature using the registered public key, without relying on shared secrets.

Workload Identity: Cloud platforms cryptographically vouch for running services, issuing very short-lived credentials dynamically. This eliminates long-lived static secrets.

Building secure applications requires following modern identity best practices.

Security Consideration	Developer Recommendation
Phishing Protection	Prioritize FIDO2/WebAuthn Passkeys over all other factors (including SMS and TOTP) for the strongest defense against credential theft.
Flow Security	Implement the Authorization Code Flow with PKCE for all clients.
Token Lifetime	Use short-lived Access Tokens (e.g., 15–60 minutes) to minimize the attack window if stolen. Use Refresh Token rotation for seamless renewal.
Token Storage	Avoid storing sensitive tokens (Access or Refresh) in localStorage or sessionStorage, due to Cross-Site Scripting (XSS) risks. For browser apps, prefer secure HttpOnly cookies for SPAs, store tokens only in memory, not in localStorage or sessionStorage. Traditional web apps should use server-side sessions with HttpOnly, secure cookies.
API Token Validation	Validate the JWT signature on every protected API request. Skipping this check is a critical security vulnerability.
Credential Protection	Enforce password hygiene with adaptive hashing (Argon2 or bcrypt) and implement rate limiting to defend against brute-force and credential-stuffing attacks. Use breached-password detection to flag known compromised credentials automatically.

What’s the difference between authentication and authorization?

Authentication (AuthN) verifies identity: “Who are you?” Authorization (AuthZ) determines access: “What can you do?” Authentication before authorization; you must prove your identity before the system checks your permissions.

Why is password-only authentication no longer secure?

Passwords are the most significant security weakness. They’re highly vulnerable to phishing and credential stuffing attacks. Modern security requires adding MFA or switching to phishing-resistant passwordless methods like Passkeys.

What is the most secure authentication method available today?

FIDO2/WebAuthn Passkeys are currently the most secure. They use public-key cryptography and are origin-bound. The credential only works for the specific domain, so attackers can’t intercept and reuse it.

What is the role of OpenID Connect (OIDC) in authentication?

OIDC extends OAuth 2.0 with identity verification. It adds the ID Token, a JSON Web Token (JWT), that provides standardized, verifiable proof of the user’s identity. OAuth 2.0 alone can’t do this.

What is the primary security risk of a stolen JWT Access Token?

A stolen Access Token lets an attacker impersonate the user until it expires. Since JWTs are stateless and hard to revoke immediately, use very short-lived Access Tokens (15–60 minutes) and Refresh Token rotation to limit the damage. Rotation detects theft immediately because the server invalidates the previous token after each use.

How does passwordless authentication work?

Passwordless authentication eliminates the need to memorize secrets. Instead, it relies on possession (e.g., a device-bound passkey or hardware key) or inherence factors (e.g., biometrics) to securely verify the user’s identity.

Authentication is foundational to application security, but it’s only the first step. To build a complete security model, you must understand how access is controlled after identity is confirmed. Explore our Intro to IAM series for additional topics related to identity and access management.

Learn more

These materials are intended for general informational purposes only. You are responsible for obtaining security, privacy, compliance, or business advice from your own professional advisors and should not rely solely on the information provided herein.