6 Authentication Methods for Secure Web Applications

In practice, authentication is the process of verifying identity before access is granted: confirming that a user or system is who they claim to be. Attackers rarely break in anymore; they log in.

Web application authentication commonly combines passwords, multifactor authentication (MFA), tokens, biometrics, single sign-on (SSO), and certificates. Related Strapi guides cover token architecture, including JSON Web Tokens (JWTs), in our JWT vs OAuth comparison; for the application programming interface (API) permissions layer, see how API authorization works.

Main takeaways:

• Modern authentication works best as a layered strategy beyond passwords
• Each method has unique strengths, including password simplicity and certificate-grade assurance
• The right approach depends on your app's security needs and user workflows, especially when data sensitivity is high
• Artificial intelligence (AI)-driven authentication and post-quantum cryptography are worth tracking as authentication requirements change

6 authentication methods for web applications

Most production architectures combine several methods.

Password-based authentication

Most web apps still use passwords by default. The user submits a credential over Transport Layer Security (TLS), the server verifies it against a stored hash, and a separate session mechanism carries the authenticated state afterward.

National Institute of Standards and Technology (NIST) SP 800-63B sets a clear bar for passwords: salted and hashed in a form resistant to offline attacks, with a minimum 15-character length for single-factor use and no forced periodic rotation. The Open Worldwide Application Security Project (OWASP) recommends Argon2id, bcrypt, or PBKDF2 for the password storage layer.

Passwords are universally understood and require no special hardware. They are a single factor, lack phishing resistant properties, and are exposed to credential stuffing and offline attacks if the password store leaks.

1. You'll want TLS on the login flow and every authenticated route.
2. For password storage, Argon2id, scrypt, or PBKDF2 with a unique per-user salt of at least 32 bits is the safer baseline, with only the salt and hash stored.
3. For single-factor passwords, 15+ characters is the target, with support for at least 64 characters and checks against breached-password lists.
4. After login, let a cryptographically secure pseudorandom number generator (CSPRNG) session ID carry the session with Secure, HttpOnly, and SameSite cookie attributes; regenerate it on privilege change.
5. Rate-limit the login endpoint and lock accounts after repeated failures.

That gives passwords a safer baseline, though they still work best as one layer in a broader authentication strategy.

In Strapi 5, the built-in POST /api/auth/local endpoint handles this flow: it accepts an identifier and password and returns a JWT. If you need custom logic, use the Document Service API rather than the deprecated strapi.query() pattern from v3/v4:

// Strapi 5: custom password check
async function verifyCredentials(email, password) {
  // Document Service API replaces strapi.query() and entityService
  const user = await strapi
    .documents('plugin::users-permissions.user')
    .findFirst({ filters: { email } });

  if (!user) return null;

  // validatePassword is async — it wraps bcrypt.compare
  const valid = await strapi
    .plugin('users-permissions')
    .service('user')
    .validatePassword(password, user.password);

  return valid ? user : null;
}

The Document Service returns unsanitized data, including password hashes, so run it through strapi.contentAPI.sanitize.output() before returning anything to a client. For a full walkthrough, follow our password authentication tutorial with Next.js 15 and password reset guide, which covers password reset, logout, and session management.

Use cases: Passwords remain the baseline for consumer apps and internal tools, especially where onboarding friction must stay low. Treat them as a starting layer and pair them with MFA for anything holding personal data.

Multifactor authentication

MFA combines different factor categories, such as knowledge, possession, and biometric factors. Two passwords do not count; the factors have to differ in kind, per the OWASP MFA Cheat Sheet.

Microsoft data cited in the OWASP Authentication Cheat Sheet suggests MFA stops 99.9% of account compromises. time-based one-time password (TOTP) codes (30-second time step under Request for Comments (RFC) 6238) and Short Message Service (SMS) codes can still be phished, and NIST now classifies restricted SMS/public switched telephone network (PSTN) authenticators because of subscriber identity module (SIM)-swap and interception attacks. WebAuthn/Fast Identity Online 2 (FIDO2) credentials are phishing-resistant because the authenticator scopes each credential to its origin; a stolen prompt on a lookalike domain fails.

1. For phishing resistance, WebAuthn/FIDO2 authentication is the safer default; TOTP can stay as a widely supported fallback, while SMS is a poor fit for high-value applications.
2. For TOTP shared secrets, at least 128 bits is the baseline; for WebAuthn, navigator.credentials.create() returns the public key credential you store.
3. Accept each one-time code only once, with a 10-minute validity window, and verify WebAuthn assertions server-side.
4. Recovery flows (backup codes, re-enrollment) matter because a lost device shouldn't lock users out permanently.

A good MFA rollout balances stronger factors with recovery paths that do not become the weakest link.

Consumer-facing MFA in Strapi requires a custom two-factor authentication (2FA) implementation: our two-part guide shows how to add 2FA in Strapi with Next.js and Nodemailer, with 2FA verification guide covering verification and session handling. For the Admin Panel, Strapi Enterprise SSO lets you delegate admin authentication to an identity provider that already enforces MFA.

Token-based authentication

The client authenticates once and receives a token it presents on later requests. RFC 7519 defines the JSON Web Token as "a compact, URL-safe means of representing claims to be transferred between two parties": a Base64URL-encoded header, payload, and signature joined by dots.

Tokens split into two roles. Access tokens credential requests to resources and work best when short-lived. Refresh tokens obtain new access tokens and, per RFC 6749, are never sent to resource servers. With Stateless token validation, the server verifies a signature locally, which suits distributed and microservice architectures. Revocation needs planning because a JWT stays valid until it expires, so server-side revocation requires a denylist keyed on the jti and iss claims. Teams tend to care about this most after a token leaks.

1. A common production pattern is to issue short-lived access tokens signed with RS256/ES256 and longer-lived refresh tokens, sent via Authorization: Bearer <token> over TLS only.
2. On the server side, plan to cover the signature, iss, aud, exp, and nbf during JWT validation. Reject alg: none tokens outright.
3. Token storage matters: tokens are safer out of localStorage; OWASP recommends HttpOnly; Secure; SameSite=Strict cookies or a backend-for-frontend pattern, since any cross-site scripting (XSS) flaw exposes everything in web storage.
4. For sensitive operations, keep and check a revocation denylist (SHA-256 digest of the token plus revocation date).
5. Refresh tokens should be rotated or sender-constrained, as RFC 9700 mandates for public clients.

Token security depends on expiration, storage, validation, and revocation discipline.

Strapi 5 offers two token models. The Users and Permissions plugin issues JWTs for end users, and its default legacy-support mode produces 30-day tokens. For production, consider switching jwtManagement to refresh mode, which issues 10-minute access tokens backed by refresh tokens; our guide on refresh token feature in Strapi walks through the pattern. Separately, API tokens authenticate applications, with read-only, full-access, and custom permission types. The Strapi authentication guide compares both, and our tutorial on authenticating Representational State Transfer (REST) requests shows them in practice.

Biometric authentication

Biometrics verify something you are, such as a fingerprint or face. In modern web applications, biometrics stay local. WebAuthn uses the device's sensor (Touch ID, Face ID, Windows Hello, Android biometrics) to authorize a locally stored private key, and the server receives only a signed assertion. The W3C WebAuthn specification states the private key is bound to its authenticator and never exposed to any other party.

NIST is careful about the limits here. SP 800-63B notes that biometric comparison is probabilistic rather than deterministic, that biometric characteristics are not secrets (faces and fingerprints can be captured covertly), and that biometrics SHALL only be used as part of MFA with a physical authenticator, never standalone.

1. For web apps, WebAuthn/passkeys are safer than custom biometric pipelines; registration calls navigator.credentials.create() with userVerification: "required".
2. Keep server-side storage to the public key credential (credential ID, public key, sign count); raw biometric samples should never be collected.
3. At login, the flow calls navigator.credentials.get() and verifies the signature, relying party (RP) ID, origin, and sign count server-side.
4. Plan lockout after five failed attempts, per NIST.
5. Keep an MFA-compliant fallback, since sensors fail.

For web applications, biometrics work best as local user verification for a cryptographic credential.

Passkeys sync across devices and bridge biometric hardware with web-native authentication. Passkey adoption is increasing. The State of Passkeys report counts five billion passkeys in active use, with 75% of consumers having one active on at least one account. Passkey sign-in succeeds three times more often than password-only sign-in (98% vs. 32%) and runs eight times faster. If you're adding biometric login to a web app, passkeys are the implementation path.

Single sign-on authentication

SSO lets a user authenticate once with an identity provider (IdP) and access multiple applications without separate logins. Enterprise federation commonly uses Security Assertion Markup Language (SAML) 2.0. OAuth 2.0 provides the authorization framework underneath many flows; OpenID Connect (OIDC) adds identity layer on top of OAuth 2.0 via the ID Token.

SSO reduces password fatigue and centralizes policy enforcement at the IdP, where MFA and session rules apply once for every connected app. SSO creates IdP risk concentration: the IdP becomes a single point of failure and a high-value target, and the SAML Security Cheat Sheet warns that IdP-initiated flows lack login cross-site request forgery (CSRF) protection by design. Service provider (SP)-initiated flows are usually the safer default.

1. Start by register your app with the IdP. Configure redirect Uniform Resource Identifiers (URIs) and logout Uniform Resource Locators (URLs), then request scopes such as openid plus profile and email.
2. Build the authorization request with response_type=code; include a state parameter for CSRF protection and a nonce against replay.
3. At the token endpoint, exchange the authorization code for ID and access tokens with response_mode=form_post.
4. Plan to validate ID tokens server-side: signature, iss, aud, exp, nonce; for SAML, validate the assertion signature and InResponseTo.
5. Create a local session, with back-channel logout so IdP sign-out clears sessions everywhere.

SSO works best when the local app treats the IdP as the policy source but still validates every assertion carefully.

Strapi supports Admin Panel SSO on the Enterprise plan and as a Growth add-on, with documented providers including Google, GitHub, Microsoft, Okta, and Keycloak via Passport.js. The Growth SSO add-on announcement covers what each tier includes. End users can also sign in through OAuth providers via the Users and Permissions plugin, as shown in our guide to authenticated API requests to Strapi. For more on social authentication, see our dedicated guide covering best practices.

Certificate-based authentication

Certificate-based authentication (mutual TLS, or mTLS) binds identity to a cryptographic key pair through an X.509 certificate. During the TLS handshake, the server sends a CertificateRequest and the client proves possession of its private key by signing the handshake, per RFC 8446. No shared secret ever crosses the wire, which makes the method resistant to phishing and credential stuffing and a natural fit for machine-to-machine and API authentication. RFC 8705 extends this to OAuth: certificate-bound access tokens can only be used by the party holding the matching private key.

Certificates add operational cost. Certificate lifecycle overhead is real, and revocation checking is easy to miss: AWS API Gateway, for one, skips revocation checks.

1. A certificate rollout usually begins with a trust anchor from a private certificate authority (CA) (AWS Private CA, Google Cloud CA Service, or an internal CA) and the CA chain exported as your truststore.
2. Give each client an X.509 client certificate with a subject Distinguished Name (DN) or Subject Alternative Name (SAN) that uniquely identifies it; the private key never leaves the client.
3. Configure the TLS terminator to request and validate certificates: upload the truststore to your gateway, or use AddAuthentication().AddCertificate() in frameworks that support it.
4. For production setups, explicit revocation checking requires certificate revocation list (CRL) or Online Certificate Status Protocol (OCSP) handling, since many managed platforms skip it.
5. Rotation works best with overlapping validity periods and expiry monitoring to avoid authentication outages.

With certificates, the security value comes from pairing strong key ownership with disciplined lifecycle management.

How to choose the right authentication method

Start with data sensitivity. Low-sensitivity consumer apps can run on passwords plus MFA. Apps holding personal data are usually planned around NIST Authenticator Assurance Level 2 (AAL2), which requires two distinct factors; NIST SP 800-63B sets AAL2 as the federal minimum whenever personal information is available online. High-assurance systems (AAL3) call for a phishing-resistant cryptographic authenticator with a non-exportable private key, such as hardware keys or passkeys.

Then layer in user experience. Passwordless passkey flows increasingly fit consumer-facing products. Enterprise workforces expect SSO tied to a central IdP. API-to-API and service-to-service traffic belongs with access tokens or mTLS, with no human in the loop.

Production systems often combine these methods. A production app might use SSO for employees while handling integrations with API tokens. For hardening the whole surface, see our guides on Strapi API security and headless Content Management System (CMS) security.

Future trends

Passkeys are moving into default flows. Microsoft has announced that passkeys become the default Entra authentication on September 1, 2026, with SMS and voice MFA fully retired on February 1, 2027. Plan for passkey support now to avoid a later retrofit.

AI-driven attacks now affect identity verification and liveness checks. The updated NIST SP 800-63-4 guidelines add threat models for AI-driven attacks and direct credential providers to deepfake signature analysis. Criminals are combining virtual-camera tools with deepfakes to bypass banking liveness checks. On defense, adaptive risk-based authentication, where AI-driven signals adjust access requirements in real time, is now baseline in workforce identity platforms.

Post-quantum cryptography now has federal standards. NIST finalized the first post-quantum cryptography (PQC) standards, including Federal Information Processing Standards (FIPS) 203, 204, and 205, in August 2024, and "harvest now, decrypt later" attacks make long-lived authentication credentials an early migration priority. Apple has already deployed post-quantum protection in iMessage and Google is testing PQC in Chrome.

Matching authentication to your app's needs

Passwords, MFA, tokens, biometrics, SSO, and certificates each solve a different slice of the same problem, and production systems combine them, including MFA on top of passwords and certificates for service traffic. Match the method to your data sensitivity and your users, and prefer phishing-resistant options wherever the stakes justify them.

Strapi 5 gives you API tokens, JWT authentication with refresh mode, role-based access control (RBAC), and enterprise SSO out of the box; the Strapi documentation covers configuration, and Strapi Cloud handles hosting with automated backups and security updates. A hands-on Strapi policies tutorial covers building with secure Strapi policies. To learn more about Strapi content workflows and API-first development, see these guides.