The Problem Every Web Application Has to Solve
Every web application that has user accounts must solve the authentication problem: verifying that the person making a request is who they claim to be. The history of authentication in web applications is a progression from simple username and password storage (often insecure) to increasingly sophisticated systems that balance security, usability, and the practical reality that most users choose weak passwords, reuse them across sites, and get phished.
The authentication landscape in 2026 has three main approaches: traditional password authentication (still the most common, now implemented with better security practices), OAuth/OpenID Connect (delegating authentication to established identity providers like Google, GitHub, and Apple), and passkeys (the newest standard, replacing passwords with cryptographic authentication tied to user devices). Understanding all three helps evaluate authentication options for web application development.
Password Authentication: The Baseline and Its Problems
Traditional password authentication — the user provides a username and password, the server verifies the password against a stored hash — remains the baseline for many web applications because it’s universally understood, doesn’t depend on third-party identity providers, and works without smartphone availability. The implementation requirements that make it adequately secure: storing passwords as salted hashes using a slow algorithm (bcrypt, Argon2, scrypt — not MD5 or SHA-256), requiring email verification to confirm account ownership, and strongly recommending or requiring MFA.
The security problems that password authentication inherits regardless of server-side implementation: users choose weak passwords, reuse passwords across sites, and fall for phishing attacks that steal credentials before they reach the server. These are user behaviour problems that no server-side implementation fully solves. The evolution of password authentication’s challenges has driven the adoption of OAuth and passkeys as alternatives.
OAuth and Social Login: Delegating the Problem
OAuth 2.0 with OpenID Connect is the protocol that enables ‘Sign in with Google,’ ‘Sign in with GitHub,’ and similar social login options. Rather than managing user credentials directly, the application delegates authentication to an established identity provider: the user authenticates with their Google account (which has strong security, MFA support, and Google’s anti-phishing defences) and Google issues a token that the application uses to identify the user.
For application developers, OAuth reduces the security responsibility: the hard parts of credential security (password hashing, breach response, account recovery) are handled by the identity provider rather than by the application. For users, social login eliminates the password creation and management step at the cost of creating dependency on the identity provider — losing access to a Google account means losing access to applications authenticated through it. The implementation complexity and privacy considerations (the identity provider learns which applications the user signs into) are the trade-offs.
Passkeys: The Password Replacement
Passkeys implement the FIDO2/WebAuthn standard described in the Cyber Security section of Vol. 1 at the application level: instead of a password, the user creates a passkey — a cryptographic key pair where the private key stays on the device, secured by biometric (fingerprint or face) or PIN authentication, and the public key is registered with the web application. Authentication is a cryptographic challenge-response that proves possession of the private key without transmitting it.
Passkeys are phishing-resistant (the cryptographic proof is bound to the specific website domain, so a phishing site can’t trigger the passkey for the legitimate site), don’t require password management (there’s nothing to remember or type), and are increasingly supported across major platforms and browsers. Apple, Google, and Microsoft all support passkeys synced across devices in their respective ecosystems. The implementation from the web developer’s perspective uses the WebAuthn API, with several libraries (SimpleWebAuthn, Auth0’s passkey support, Hanko) simplifying the integration.
Choosing an Authentication Strategy
For most new web applications: implement OAuth/social login as the primary flow (reducing friction for users with existing Google or GitHub accounts), offer password authentication as a fallback for users who prefer it or don’t have social login credentials, and add passkey support as it becomes standard browser behaviour. This combination covers the broad range of user preferences without requiring users to create yet another password.
The infrastructure decision behind authentication: build your own versus use a service. Building custom authentication correctly is a security-critical task that many teams underestimate — session management, CSRF protection, secure credential storage, account recovery, and rate limiting all have failure modes with significant consequences. Authentication-as-a-service platforms (Auth0, Firebase Authentication, Clerk, Supabase Auth) handle these correctly and cost less than the engineering time to implement them correctly from scratch. For most applications, using an established authentication service rather than building custom authentication is the right decision.