Authentication UI
Authentication UI is the part of an application where users sign up, sign in, prove a second factor, and recover accounts. It's the front door for every user, so it has to be fast and frictionless — and it's also the most attacked surface in the product, so it has to resist credential stuffing, phishing, enumeration, and token theft.
Most security of authentication happens on the server: password hashing, session management, and token validation (see Authentication). But the browser side decides whether password managers work, whether passkeys are offered, where tokens live, and what attackers can learn from error messages. Small UI decisions have large security and conversion consequences.
TL;DR
- Use real
<form>elements with correctautocompleteattributes so password managers and passkeys work. - Offer passkeys (WebAuthn) and support MFA with accessible one-time-code inputs.
- Show generic errors ("Incorrect email or password") to avoid account enumeration.
- Store sessions in
HttpOnly,Secure,SameSitecookies; avoid long-lived tokens inlocalStorage. - Protect flows with CSRF defenses, rate limiting, and bot protection on the server.
- Make every step accessible: labels, visible errors, no time pressure, paste allowed.
Quick Example
A login form that password managers, passkey autofill, and screen readers understand:
Offering passkeys through conditional mediation (the browser shows saved passkeys in the username field's autofill menu):
A one-time-code field for MFA that supports SMS autofill on mobile:
Core Concepts
Autocomplete Attributes
Authentication Methods in the UI
- Passwords — still common; pair with breach checks and MFA. See Password Security.
- Passkeys / WebAuthn — phishing-resistant, no shared secret; offer during signup and via autofill. See Passkeys & WebAuthn.
- Magic links and email codes — passwordless, but vulnerable if email is compromised.
- Social login / SSO — "Continue with Google" or enterprise SSO via OAuth and OIDC; reduces passwords but adds provider dependency.
- MFA — TOTP apps, security keys, push, SMS (weakest). See MFA.
Sessions and Token Storage
The backend-for-frontend (BFF) pattern keeps OAuth tokens on the server and gives the browser only a session cookie — the safest model for SPAs. See JWT for token pitfalls.
Account Enumeration
Messages like "No account with that email" or different response times for known vs unknown emails let attackers discover valid accounts. Use generic messages for login and password reset ("If an account exists, we've sent a link"), and keep response timing consistent.
Protecting the Flow
Server-side controls the UI must accommodate: rate limiting and lockout backoff, CAPTCHAs or bot scoring after suspicious attempts, CSRF tokens on form posts, and a strict Content Security Policy against XSS. Re-authenticate before sensitive actions like changing email or disabling MFA.
Best Practices
Let Password Managers Work
Use one form, proper autocomplete, stable field names, and allow paste. Blocking paste pushes users toward weak, memorable passwords.
Separate Identifier and Password Steps Carefully
Two-step flows (email first, then password or SSO) help route enterprise users to SSO, but keep the password field in the DOM (hidden) or use proper autocomplete so managers still fill it.
Offer Passkeys Prominently
Prompt users to create a passkey after sign-in and use conditional mediation so returning users can sign in with one tap.
Write Helpful, Safe Errors
Say what the user can do ("Check your email and password, or reset your password") without revealing whether the account exists.
Make Recovery as Strong as Login
Account recovery is often the weakest link. Require verified channels, notify users of changes, and add delays or review for high-risk changes.
Design for Accessibility
Label every input, announce errors with role="alert", don't use time-limited codes without a way to resend, and avoid CAPTCHAs that exclude users without alternatives. See Accessibility.
Common Mistakes
Storing Refresh Tokens in localStorage
A single XSS bug can steal long-lived credentials. Use HttpOnly cookies or a BFF.
Account Enumeration Through Messages or Timing
"Wrong password" versus "no such user" hands attackers a validated email list.
Custom JavaScript "Forms" Without <form>
Div-based inputs break password managers, Enter-to-submit, and assistive technology.
Password Rules That Hurt Security
Composition rules and forced rotation encourage predictable passwords. Prefer length minimums and breached-password checks, per NIST SP 800-63B.
Silent Session Expiry
Kicking users out mid-form loses work. Warn before expiry, refresh sessions when active, and preserve form state.
FAQ
How should I store auth tokens in a single-page app?
Prefer an HttpOnly, Secure, SameSite session cookie, ideally through a backend-for-frontend that holds OAuth tokens server-side. Avoid storing long-lived tokens in localStorage.
What autocomplete values should a login form use?
username (or username webauthn) for the identifier and current-password for the password. Use new-password on signup and reset forms and one-time-code for OTP inputs.
Should I show "Email not found" on the login page?
No. Use a generic message to avoid revealing which emails have accounts, and apply the same approach to password reset.
Are passkeys ready for production?
Yes. All major browsers and platforms support passkeys, and password managers sync them. Offer them alongside existing methods and encourage enrollment after sign-in.
Is SMS a good second factor?
It's better than nothing but vulnerable to SIM swapping and phishing. Prefer authenticator apps, security keys, or passkeys.
Related Topics
- Authentication Strategies — Server-side sessions, tokens, and passwordless
- Passkeys & WebAuthn — Phishing-resistant sign-in
- Multi-Factor Authentication — Second factors and their trade-offs
- OAuth 2.0 & OpenID Connect — Social login and SSO flows
- Forms & Validation — Accessible, resilient form UX