Authentication: stop losing your users at the login screen

The login page is often the first real friction a user encounters in your product. And according to the Baymard Institute, 52% of users abandon a sign-in process they consider too long or too complex. On mobile applications, this figure sometimes reaches 60% on the first login. This is not a security problem — it is a design problem.

The real cost of the password

The average user manages more than 100 online accounts today. According to LastPass, 65% of people reuse the same password across multiple sites. Faced with the impossibility of memorizing everything, people choose weak or identical passwords everywhere — exactly what security policies are trying to prevent. The traditional login form has thus become a losing compromise: it slows down legitimate users without truly stopping bad actors.

The support-side statistics are equally telling: password resets account for 30 to 40% of first-level tickets in most organizations. This invisible operational cost translates to thousands of wasted hours every year.

New approaches: fewer passwords, more context

Magic links — email as the second factor

The concept is radical in its simplicity: the user enters only their email address, and receives a single-use link valid for a few minutes. One click, and they are logged in — with no password to remember.

This approach is particularly effective for low-frequency products, where users sign in only a few times a month and inevitably forget their credentials. Tools like Stytch or Magic are built entirely around this pattern. Industry data shows a 20 to 30% improvement in signup conversion rates compared to the classic form.

The main limitation: it assumes access to the email inbox is secure. If the email account is compromised, all linked services are too. This is why magic links work best on applications where data is not highly sensitive, or when combined with a second factor.

SSO — delegating identity

Single Sign-On lets users authenticate via an existing account: Google, Apple, GitHub, or a corporate system via SAML / OpenID Connect. The advantage is twofold: zero additional passwords for the user, and access to an identity already verified by a trusted party.

In B2C, Sign in with Google or Continue with Apple buttons reduce account creation time from several minutes to a few seconds. In B2B, enterprise SSO (Microsoft Entra, Okta, Google Workspace) is often a non-negotiable requirement from IT teams who do not want to manage external accounts outside their security perimeter.

Passkeys — the announced end of the password

Passkeys, standardized by the FIDO Alliance under the WebAuthn protocol, represent the most structural change in decades. Instead of a password, an asymmetric key pair is created: the private key stays on the device, unlocked by biometrics (Touch ID, Face ID, Windows Hello); the public key is registered on the server. The user types nothing — they place a finger or glance at the screen.

Apple integrated passkeys natively in iOS 16 and macOS Ventura, synchronized via iCloud Keychain. Google offers them on Android and Chrome. Bitwarden and 1Password, long confined to passwords, have both added passkey management, which solves the multi-device problem: the passkey stored in the manager is available everywhere, regardless of browser or OS.

Adoption is growing rapidly: Apple, Google, PayPal, eBay, and Shopify have all deployed passkeys in production. The measured results are unambiguous — PayPal reported a reduction in login abandonment of several dozen percentage points after deployment.

→ See also: Two-factor authentication

Bad practices that drive users away

The login screen is a domain where bad practices accumulate, often inherited from an era when security took absolute precedence over experience.

Overly aggressive session expiration. Disconnecting a user after 15 minutes of inactivity on a banking application is justifiable. Doing the same on an analytics dashboard or a project management tool generates frustration without any real benefit. Session duration should be proportional to data sensitivity.

Systematically re-prompting for MFA. If every visit requires TOTP or SMS validation, even from the same device and network, users will eventually disable the second factor — or abandon the service. Maximum security taken to an extreme produces the opposite of the intended effect.

Artificial password complexity. Requiring at least one uppercase letter, one digit, one special character and a minimum length of 12 characters leads to P@ssw0rd12! rather than a genuine passphrase. Current NIST guidelines point in the opposite direction: favor long, natural phrases and eliminate mandatory periodic rotations.

Too many clicks to sign in. Every additional step costs conversions. A two-page login form, a poorly calibrated CAPTCHA, a mandatory email verification before even the first session — every unnecessary friction means a lost user.

Recognizing the device: the key to balance

Adaptive authentication (or risk-based authentication) involves modulating the verification level based on context: known or unknown device, familiar location, time of day, suspicious behavior. A user logging in from their usual iPhone on their home network does not need the same treatment as a login from an unknown country at 3 AM.

The remember this device mechanism — often via a long-lived cookie or token — allows a second factor to be requested only on the first sign-in on a device, then trusts the recognized device thereafter. This is the solution to intrusive MFA: security remains present but invisible for the regular user.

The special case of banks and institutional actors

Banks, insurance companies, and public bodies are often behind on these developments — and it is not purely technological conservatism. Regulatory constraints (PSD2 in Europe, eIDAS, FFIEC in the United States) impose strong authentication levels that leave little room for maneuver. The liability risk in case of fraud creates a natural aversion to any simplification perceived as a weakening of security.

PSD2 requires Strong Customer Authentication (SCA): for online payments, the user must validate via two distinct factors. This legal framework makes magic links or long sessions impossible for sensitive operations, even if the bank wanted them.

That said, neobanks like N26, Revolut, and Bunq prove it is possible to comply with these constraints while offering an experience far superior to legacy players: smooth mobile onboarding, biometrics as the primary factor, smart push notifications. Regulation is a constraint, not an excuse for a 2000s-era UX.

Keycloak and market solutions

For teams wanting to outsource identity management — without reinventing the wheel — the market today offers a wide spectrum, from self-hosted open source to premium SaaS.

Keycloak (Red Hat / CNCF) is the open source reference. It supports OIDC, SAML, LDAP, Active Directory, and offers fully customizable authentication flows. Its main asset is total control: data hosted on-premise, with no vendor dependency. The tradeoff is the operational effort — deployment, updates, monitoring. It is particularly adopted in regulated environments where data sovereignty is non-negotiable.

Solution	Model	Pricing	Strengths
Keycloak	Open source, on-premise	Free	Full control, SAML/OIDC, customizable
Auth0 (Okta)	SaaS	Freemium	Rich SDKs, flow flexibility
Okta	SaaS	Paid	Enterprise, SSO, lifecycle management
AWS Cognito	SaaS	Pay-as-you-go	Native AWS, scalable
Clerk	SaaS	Freemium	Developer DX, built-in UI components
Stytch	SaaS	Freemium	Native magic links and passkeys
Microsoft Entra ID	SaaS	Included in M365	Microsoft ecosystem, enterprise
FusionAuth	Hybrid	Freemium	Flexible deployment, partially open source

Clerk and Stytch stand out as developer-oriented solutions: well-documented SDKs, ready-to-use UI components, and onboarding measured in hours rather than days. For a startup-phase project or a team without dedicated IAM expertise, they often represent the best effort-to-outcome ratio.

What this means for your next project

There is no universal authentication architecture — the right solution depends on the user profile, data sensitivity, and regulatory constraints. But a few principles apply universally:

• Minimize steps for the nominal case (regular user, known device)
• Strengthen security contextually and silently, not systematically
• Offer SSO as soon as the target audience has a federable identity (Google, Apple, enterprise)
• Adopt passkeys as the primary mechanism on mobile, with email fallback
• Delegate to an IdP rather than implementing cryptography and flows yourself

Security and user experience are not opposed. They only become so when you apply policies designed for a different context than your own.