Authentication Page UX: A Security, Recovery, and Accessibility Guide

An authentication page has a narrow job: help the right person enter the product, explain what happens next, and provide a safe route out of every foreseeable failure. It does not need invented conversion benchmarks or a gallery of fashionable login screens.

This guide treats authentication as a service journey. The interface, delivery channel, identity provider, session policy, and recovery path all have to work together. Security guidance comes from the OWASP Authentication Cheat Sheet; accessibility checks link to the relevant W3C guidance.

Start with the authentication model

Choose the supported methods before designing the page. Each method creates different states and recovery obligations.

Method	What the person needs	States the interface must cover
OAuth	An account with the selected provider	Provider redirect, cancellation, consent error, callback error, blocked account
Email magic link	Access to the submitted inbox	Sending, sent, resend cooldown, expired link, used link, wrong device
Password	A stored credential and recovery channel	Sign in, create account, reset, locked account, changed password
Passkey	A compatible device or credential manager	Registration, sign in, unavailable credential, fallback method

Do not add a method because another product uses it. Add it when the intended audience can use it and the team can operate its failures. A passwordless flow still depends on email delivery. OAuth still depends on provider configuration and a callback route. Passkeys still need a fallback and account-recovery policy.

Give each page one primary task

The page title, first field, primary button, and supporting copy should agree on the task. If a product combines registration and sign-in, say so directly, for example: “Enter your email to continue.” If it separates them, use distinct labels such as “Create account” and “Sign in.”

A practical information order is:

1. Product identity and a short task heading.
2. The preferred authentication method.
3. A clearly labelled alternative, if one exists.
4. A status or error area close to the affected control.
5. Privacy and terms links.
6. A route to the other account state only when the product separates registration from sign-in.

Ask only for information needed to authenticate. Profile details, onboarding questions, and marketing preferences belong after the account exists. This reduces the number of failure points and avoids making consent or optional profile data appear necessary for access.

Design the full magic-link journey

The email form is only the first screen. A usable magic-link flow also needs a sent state that:

• repeats the destination address so the person can spot a typo;
• says that the message contains a sign-in link;
• provides a resend action with a visible cooldown;
• offers a way to change the address;
• explains link expiry without promising an exact duration unless the server enforces it;
• keeps the original tab useful if the link opens elsewhere.

The error state should describe the next action. “Link expired. Request a new link” is more useful than “Invalid token.” Do not reveal whether an account exists when that distinction would enable account enumeration. OWASP recommends consistent authentication responses and timing where different responses would disclose account validity.

Email delivery is operational work, not just interface work. Monitor send failures, bounces, provider latency, and callback completion. Use single-use, time-limited tokens, protect the request endpoint from abuse, and never place a reusable credential in analytics or logs.

Our shared implementation keeps the sent state opt-in, shows the submitted address, supports resend cooldowns, and provides client-specific inbox links. It is a reference implementation, not evidence that the same copy or timing fits every audience.

Treat OAuth as a redirect, not a button decoration

An OAuth button should identify the provider and initiate one predictable action. Follow the provider’s branding requirements, request only the scopes the product needs, and ensure the public product name, homepage, privacy policy, and consent-screen identity agree. Google documents these requirements in its OAuth verification guidance and app identity guidance.

For a web application, test at least:

• the production origin and exact callback URI;
• a person who cancels at the provider;
• an account that is not permitted by product policy;
• a callback with missing or invalid state;
• a provider outage or network interruption;
• returning users and first-time users;
• the test-to-production transition in the provider console.

Do not put an OAuth secret in client code. Store it in the server environment and configure the identity provider with the exact callback URI produced by the authentication framework.

Make errors useful without leaking account state

WCAG 2.2 success criterion 3.3.1 requires an automatically detected input error to identify the item and describe the problem in text. Colour, an icon, or a border can supplement that description but cannot replace it.

Good authentication errors have three parts:

1. What failed, at the level it is safe to disclose.
2. What the person can do next.
3. Whether their entered value has been preserved.

Examples:

Situation	Useful response
Invalid email format	“Enter an email address in the format name@example.com.”
Magic-link send failure	“We could not send the link. Try again, or use Google sign-in.”
OAuth cancellation	“Google sign-in was cancelled. You can try again or use email.”
Expired link	“This sign-in link has expired. Request a new link.”
Generic credential failure	“We could not sign you in with those details.”

Focus the error summary or first invalid control when a submission fails, and connect inline errors to their inputs. Status changes such as “Link sent” should be available to assistive technology without unexpectedly moving focus; see the W3C explanation of status messages.

Keep the page accessible at every state

The minimum release check includes:

• one visible label for every input;
• a logical heading order and a unique page title;
• keyboard access to every action;
• a visible focus indicator;
• text descriptions for errors;
• autocomplete values that match the field purpose;
• no information conveyed only by colour;
• provider logos with an accessible button name;
• legal and recovery links with meaningful text;
• zoom and narrow-screen testing;
• screen-reader checks for sent, loading, and error states.

Avoid automatic focus unless testing shows that it improves the task without hiding context. Never use a placeholder as the only label. Do not disable the submit button so completely that the person cannot discover why submission is unavailable.

Separate interface state from security state

The browser can improve feedback, but the server remains authoritative. Server routes must validate inputs, enforce rate limits, verify tokens, apply session policy, and return safe error categories. A client-side “authenticated” flag is not an authorization decision.

The same separation applies after sign-in. Authentication establishes identity. Authorization determines what that identity may do. Sensitive actions should re-check authorization on the server even when the interface has hidden the control.

Measure the journey with first-party events

External case studies do not predict a product’s result. Establish a baseline from the actual journey instead. Useful events include:

• auth page viewed;
• method selected;
• OAuth redirect started;
• magic link requested;
• send accepted or failed;
• callback completed or failed by safe error category;
• resend requested;
• authentication completed.

Do not send email addresses, tokens, provider responses, or other credentials to analytics. Segment only by non-sensitive context such as device class, authentication method, or new versus returning journey when that distinction is safely available.

The primary diagnostic ratios are step-to-step completion and the distribution of recoverable failures. A higher click rate on a provider button is not success if callback errors also rise.

Release checklist

Before publishing an authentication change:

1. Confirm the supported methods and account policy.
2. Exercise every sent, cancelled, expired, and recovery state.
3. Verify production origins, callback URIs, secrets, and provider status.
4. Check server-side validation, rate limits, token handling, and authorization.
5. Run keyboard, zoom, contrast, and screen-reader tests.
6. Confirm privacy and terms links resolve from the production hostname.
7. Inspect analytics payloads for personal data and credentials.
8. Compare completion and failure categories against the pre-change baseline.

Authentication UX is reliable when it gives the right person a clear path forward and gives an attacker as little useful information as possible. Both outcomes are observable, and neither requires a universal conversion claim.

Sources and implementation references

• OWASP Authentication Cheat Sheet
• W3C: Error Identification
• W3C: Status Messages
• Google OAuth verification requirements
• Google OAuth app identity and branding
• Auth.js authentication documentation
• BY Group shared authentication UI