Authentication Page Design Guide: Login UX, Magic Links, OAuth & Conversion

Authentication pages are the gateway to your product. Every user who becomes a customer must pass through your login or registration flow at least once. Despite this, most auth pages are designed by convention rather than evidence — copying patterns from other products without understanding why those patterns exist or whether they work.

This guide synthesises research from Baymard Institute, NNGroup, Smashing Magazine, Google, Apple, and OWASP into a single reference for designing authentication pages that convert visitors into users while maintaining security and accessibility. It covers the full auth experience: login pages, registration flows, magic link verification, OAuth integration, error recovery, and the countless micro-decisions that determine whether a user completes sign-up or abandons.

Unified vs Separate Login/Signup Pages
Auth Page Layout and Visual Hierarchy
Magic Link UX
OAuth and Social Login
Form Fields and Conversion Impact
CTA Button Text and Visual Hierarchy
Error Handling and Recovery
Loading States and Perceived Performance
Mobile-Specific Considerations
Accessibility
Common Anti-Patterns
Conversion Optimization
Bringing It All Together: A Standard Auth Pattern
Component Specification
References

Unified vs Separate Login/Signup Pages

The Research Consensus

The question of whether to use a single page for both login and registration or separate pages depends primarily on the authentication method. For magic link / passwordless flows, the distinction between login and signup is functionally meaningless — the user enters their email and clicks a link regardless of whether they are new or returning.

Evidence for Unified (Email-First) Flows

NNGroup’s Trust Pyramid identifies 5 levels of user commitment. Registration falls at Level 3 (“Trust with Personal Information”), meaning users must first pass through Level 1 (baseline relevance) and Level 2 (interest). Demanding registration as a gate to the product violates this hierarchy. A unified flow with a single email field represents a lower commitment level than a dedicated “Create Account” page with multiple fields (NNGroup).

Baymard Institute found that 19-26% of shoppers abandon specifically because “the site wanted me to create an account.” This ranks as a top-5 abandonment driver. Baymard recommends delaying account creation — 42% of e-commerce sites fail to do this (Baymard).

Authgear’s 2025 guide states: “A combined login/sign-up form can reduce friction — users just enter their email/phone once and the system figures out if they’re new or returning.” However, it warns: “If users get confused by a combined form, separate the flows” (Authgear).

Magic links inherently unify login and signup because the flow is identical: enter email, check inbox, click link. The system handles new vs. returning user detection server-side. There is no password to “create” during signup, which eliminates the primary differentiator between login and registration forms.

Evidence for Separate Pages

Most leading SaaS products still use separate pages, though with unifying elements:

Product	Pattern	Auth Methods
Linear	Separate login/signup	Google, Email link, SAML SSO, Passkey
Figma	Separate login/signup	Google, Email+Password, SSO
Vercel	Separate login/signup	Email, Google, GitHub, SAML SSO, Passkey
Notion	Unified	Google, Apple, Magic link (4-word code), SSO
Slack	Hybrid (email-first)	Email code, Google, Apple

Common patterns across these products: the login page is the primary entry, “Continue with…” language is used instead of “Log in with…”, social/SSO options are prominent, and the signup link is secondary (small text at the bottom).

When Each Pattern Works Best

Use unified (email-first) when:

Your auth method is passwordless (magic link, OTP, passkey)
Signup requires minimal data beyond email
You serve B2B SaaS users who need SSO domain routing
You prioritise conversion over upfront data collection
Your product is mobile-first

Use separate pages when:

Signup requires substantial additional information (name, organisation, role, billing)
You use traditional email+password authentication (login and signup forms look fundamentally different)
Signup triggers a multi-step onboarding wizard
Your users expect the convention (most SaaS products use separate pages)

Our Recommendation

If you use magic links, a unified flow is the natural fit. The distinction between login and signup is handled server-side. Maintaining separate sign-in and sign-up pages adds routing complexity without clear benefit. A single email field and a single page handles both cases.

Auth Page Layout and Visual Hierarchy

Material Design 3 Recommendations

MD3 does not define a specific “authentication” canonical layout, but the auth screen fits the single-pane focus pattern: a centered card with constrained max-width (400-480dp), or a split layout on large screens with branding on one side and auth form on the other.

Recommended visual hierarchy (top to bottom):

App logo / brand mark — establishes trust and context
Headline (“Sign in” / “Get Started”) — Headline Large (32px) or Medium (28px)
Social sign-in buttons (Google, Apple) — displayed prominently
Divider with “or” — separates social from email auth
Email text field — outlined, with label
Primary CTA — Filled button, full-width within the form
Secondary navigation — “Don’t have an account? Sign up” as text button

MD3 uses an 8dp baseline grid for all spacing. Touch targets must be at least 48x48dp with 8dp or more space between them. Typography: Body Large (16px) for input text and labels, Label Large (14px) for button text (MD3 - Layout, MD3 - Typography).

Apple HIG Recommendations

Apple’s primary recommendation is to delay requiring sign-in for as long as possible. Let users explore and understand value before requesting commitment. Only ask for sign-in in exchange for clear value — personalisation, additional features, or data synchronisation (Apple HIG).

On the sign-in screen, provide a brief, friendly description of the benefits of creating an account. Apple’s design principles for auth:

Clarity: Make the primary action (sign in) visually dominant. Use clear labels. Avoid jargon.
Deference: Do not overwhelm users with unnecessary decoration. Keep the focus on the task.
Depth: Use visual layering for modal states. Transitions should feel natural and spatial.

The Video Background Question

Research is cautionary about video backgrounds on auth pages. Forbes reports hero videos can boost landing page conversion by 80%, but Studio1 Design found that video backgrounds on pages with complex offers (like signup forms) hurt conversions because they distract from the primary action. “Almost all sites using video backgrounds lost sales because of them” (Studio1 Design, Unbounce).

First-time visitors form an impression in 50 milliseconds (purely visual). The form itself should have maximum visual clarity with generous whitespace. If using a video background, it should be heavily dimmed (low opacity) so it does not compete with the form for attention.

Recommendation: If you use a video background for brand identity, ensure the glass/card form area has strong enough contrast and blur to prevent distraction. Consider A/B testing a static illustration or branded gradient against the video to measure conversion impact.

The “OR” Divider Pattern

Use a thin horizontal rule with lowercase “or” centered in it. Keep it visually subtle. The divider should communicate “alternative path” without creating anxiety about which method is “correct.” Up to 3 OAuth options is acceptable above the divider; more than 3 creates choice paralysis (Authgear, Descope).

Magic Link UX

User Understanding

Most users understand magic links through exposure to Slack, Notion, and Medium. However, initial user feedback consistently shows confusion from users expecting traditional login forms, particularly when organisations first transition to passwordless. The messaging “No password needed, just your email” helps address this.

Power users experience regression: Users who already use password managers find magic links slower than autofilled passwords. The benefit is primarily for non-technical users (BayTech Consulting).

Conversion Data (with caveats)

Company	Metric	Source
Notion	Onboarding completion: 64% to 87%	BayTech (vendor-sourced)
Substack	41% increase in newsletter subscriptions	BayTech (vendor-sourced)
Slack	82% of new team members onboard within 5 minutes	BayTech (vendor-sourced)
Calendly	Registration completion: 43% to 71%	BayTech (vendor-sourced)
Figma	91% first-attempt magic link success	BayTech (vendor-sourced)
General	Sign-up completion +40-60% vs password	BayTech (vendor-sourced)
General	~10% of active users stuck in password reset monthly; 75% quit	Authgear

Critical caveat: BayTech Consulting’s thorough analysis found that “most quantitative claims come directly from authentication vendors who have a commercial interest in promoting the technology.” There is a “glaring absence of independent, detailed case studies.” The business case rests more on plausible theory than independent empirical evidence (BayTech).

The “Check Your Email” Page

This is the highest-risk moment in the entire authentication flow. The user has completed their action but has no feedback loop until the email arrives.

Best practices:

Clear, specific instructions beat vague ones. Show numbered steps: “Open your email inbox”, “Look for email from [your product]”, “Click the sign-in link”. Include a spam/promotions folder tip.
Show the exact email address the link was sent to. Users with multiple accounts often forget which one they used.
Add “Open Gmail” / “Open Outlook” deep link buttons. Detect the email domain and show the appropriate deep link. This directly addresses the #1 friction point: context switching to the email client.
Communicate link expiry: “This link expires in 15 minutes” sets expectations and reduces support requests.
Offer resend with a cooldown timer (60 seconds). Show “Resend in 45s” while cooling down, then “Resend” when available. After 2-3 resends, suggest an alternative: “Still not receiving emails? Try signing in with Google instead.”
Offer OAuth as an escape hatch: When users are stuck waiting for email, showing “Or sign in with Google” on the verify page gives them an immediate fallback.

Email client deep link logic:

gmail.com, googlemail.com     → https://mail.google.com/
outlook.com, hotmail.com, live.com → https://outlook.live.com/
yahoo.com, ymail.com          → https://mail.yahoo.com/
Other                         → Do not show a deep link button

Email Delivery Speed

Users expect magic links within seconds. Even a 1-minute delay creates uncertainty and frustration. Postmark benchmarks transactional email delivery at under 10 seconds. One organisation’s 20-30 second delivery times led them to reintroduce password alternatives.

Token expiry: Industry practice converges on 10-15 minutes, with 15 minutes being the most common. The email itself should state “This link will expire in [X] minutes for your security.”

Cross-Device Problem

User starts login on laptop, checks email on phone, clicks link on phone. The phone gets authenticated but the laptop does not.

Approach	Used By	Trade-off
Require same device/browser	Clerk (default), Okta	Safest but frustrating
Allow cross-device, auth the clicking device	Many providers	Leaves original device unauthenticated
Polling on original device	Slack, custom implementations	Original device auto-detects auth and redirects
Show OTP as fallback	Glitch, WorkOS	User types code on original device

WorkOS deprecated magic links entirely in favour of 6-digit OTP codes, specifically citing cross-device issues. Clerk’s default is “Require the same device and browser.”

Recommendation: Implement polling on the verify page so when the magic link is clicked on any device, the original page auto-redirects to the authenticated state (Clerk, WorkOS).

Corporate Email Scanner Problem

Corporate email security scanners (Outlook SafeLinks, Proofpoint, Barracuda) pre-click magic links before users, consuming single-use tokens. This is a well-documented issue across auth providers.

Mitigations:

Use a confirmation page after clicking (button to confirm “Yes, sign me in”) instead of immediate authentication on GET request
Handle HEAD requests without invalidating tokens
Allow multiple uses within the expiry window (trade security for reliability)

Email Deliverability

Stytch found that even single-word differences in email subject lines materially affected inbox placement. “You’re invited to join [Product]” had significantly higher primary inbox placement than “You’re invited to [Product].” HTML graphics affect whether messages land in the Promotions tab.

Use unique email subject lines per send (e.g., include timestamp) to prevent Gmail threading of multiple magic link emails. Add anti-threading headers (References, In-Reply-To) (Stytch).

Conversion Impact

OAuth is one of the highest-impact conversion levers available:

Company/Study	Metric	Source
Heap (79 SaaS sites)	One-click OAuth: +8.2 percentage points	Heap
Axel Springer	Google One Tap: 14x more registrations	Google Developers
KISSmetrics	Sign-up engagement: 11% to 59.7% (+314%)	il.ly
GenPPT	Trial starts: +107% from prominent Google login	il.ly
Pinterest	+47% desktop, +126% Android from Google One Tap	Google Developers
Reddit	~2x new user signup conversion with Google One Tap	Google Developers
General	SSO typically increases sign-ups by 20-40%	Auth0

In B2C apps, social login accounts for 55% of logins, magic links 30%, passwords only 4% (BayTech).

Placement Best Practice

Place OAuth buttons (Google, Apple) above the email form. This follows the “path of least resistance first” principle. Limit to 2-3 OAuth providers maximum. Avoid showing more than 3 options above the divider — this creates choice paralysis (Authgear).

Google recommends deploying both the standard Button and One Tap using the same OAuth Client ID. One Tap auto-displays on page load (no gesture required) and supports automatic sign-in for returning users (Google).

Google Button Requirements

Branding specifications (must be followed):

Theme	Fill	Stroke	Font
Light	`#FFFFFF`	`#747775` (1px inside)	Roboto Medium 14/20
Dark	`#131314`	`#8E918F` (1px inside)	Roboto Medium 14/20
Neutral	`#F2F2F2`	None	Roboto Medium 14/20

Must be displayed “at least as prominently as other third-party sign-in options”
Text options: “Sign in with Google”, “Sign up with Google”, or “Continue with Google”
The Google “G” logo must remain standard colour on white background
Never use the icon alone without text or monochrome logo versions
Preserve aspect ratio at all sizes

(Google - Branding Guidelines)

If your app supports any third-party or social login, Apple relaxed the strict mandate in early 2024 but still recommends offering Sign in with Apple or an equivalent privacy-preserving option.

Button rules:

Only three allowed titles: “Sign in with Apple”, “Sign up with Apple”, “Continue with Apple”
Logo and text must be either black or white — no custom colours
Must be no smaller than other sign-in buttons
Avoid making people scroll to see the button
Apple recommends placing its button above rival sign-in buttons

(Apple HIG - Sign in with Apple)

Form Fields and Conversion Impact

The Data

Change	Impact	Source
3 fields (optimal)	~10% average conversion rate	Mailmunch
Reducing 11 to 4 fields	+120% conversion	Neil Patel
Reducing 4 to 3 fields	+50% conversion	DashClicks
Removing 1 field (on average)	+50%	DashClicks
Reducing 9 to 6 fields	+25% signups	Authgear
Removing confirm password	+56.3% conversion	CXL
Firms with <5 fields vs >5	+20% conversions	Mailmunch

83% of users report frustration with complex signup forms and have abandoned their attempt. 67% of registration abandonments occur at password creation (Calendly data).

When to Collect Name Fields

The research suggests collecting name fields during registration may hurt conversion:

Each additional field may drop conversion by 8-50% depending on context
However, Michael Aagaard’s study found that removing fields without improving clarity can decrease conversion by 14%. If you need a field, keep it — but explain why.
Progressive profiling (collecting data after registration) is preferred by NNGroup’s trust pyramid: provide value first, request information afterward.

Recommendation: A single email field is optimal for magic link auth. Defer name collection to a post-auth onboarding step or profile page. Only collect information during registration that is genuinely required before the user can get value from the product.

Text Field Choice

Material Design 3 recommends outlined text fields for forms where multiple fields appear together. Filled text fields are better for isolated inputs (search bars). Never mix filled and outlined in the same region (MD3 - Text Fields).

CTA Button Text and Visual Hierarchy

Button Text Research

“Get Started” outperforms “Sign Up” and “Contact Us” because it feels less committal
First-person language increases engagement: “Start my free trial” outperforms “Start your free trial”
Action-oriented phrasing reduces hesitation: “Continue” implies forward progress
Avoid “Sign Up” and “Sign In” together — the single-letter difference (“up” vs “in”) causes confusion. Use distinct word pairs: “Create Account” / “Sign In” or “Register” / “Log In” (Learn UI Design, Echobind)

Button Hierarchy (Material Design 3)

Button Type	Emphasis	Auth Form Usage
Filled	Highest	Primary CTA: “Send magic link”, “Continue with Email”
Filled Tonal	Medium-high	Secondary prominent action: “Sign in with Google”
Outlined	Medium	Secondary actions: “Sign up instead”, “Back”
Text	Lowest	Tertiary links: “Forgot password?”, “Terms of service”

The primary submit button should always be a Filled button. Text buttons are appropriate for “Forgot password?” and navigation links (MD3 - Buttons).

Apple HIG Button Hierarchy

Use a consistent style hierarchy to communicate importance. Use the visually prominent filled style for the primary action (e.g., “Sign In”). Use less prominent styles for secondary actions (e.g., “Create Account”, “Forgot Password”) (Apple HIG).

Toggle Link Between Login/Signup

Place “Already have an account? Sign In” as a subtle text link below the form submit button. The secondary action should be clearly subordinate visually to prevent confusion about which form the user is on. Use distinct word pairs to avoid the “Sign Up” / “Sign In” confusion (Uxcel).

Error Handling and Recovery

Error Message Placement

NNGroup’s guidelines are unambiguous: inline validation is the gold standard. Error messages must appear directly adjacent to the problematic field. Toast notifications are unsuitable for form errors because they disappear before users can act on them (NNGroup).

Rules:

Use inline error messages below the field, styled with error colour and icon
Never use toasts for form validation errors. Reserve toasts for success confirmations only (“Magic link sent!”)
If multiple errors, show an error summary at the top AND inline errors at each field
Do not show errors while the user is still typing. Validate on blur or on submit
After 3+ repeated identical errors, reconsider the field design itself

(Smashing Magazine, NNGroup)

“Email Not Found” vs “Wrong Password” — Security vs Usability

OWASP recommends generic messages to prevent account enumeration. However, the security benefit is marginal for consumer apps because attackers can determine account existence via the signup flow anyway.

For magic-link-only flows (no password), you can be more specific (“We couldn’t find an account with that email”) because there is no password to enumerate against. Always pair the error with a recovery action: include a “Send magic link” or “Create account” link in the error message. Never clear the email field after a failed attempt (OWASP, Skycloak).

Expired Magic Link Recovery

Industry standard is 10-15 minutes for magic link validity. The expired link page must contain:

A clear, jargon-free explanation: “This link has expired. Magic links are valid for 15 minutes.”
A pre-filled email field (extracted from the token or URL parameter)
A single prominent button: “Send a new link”
After clicking: “A new link has been sent to [email]. Check your inbox.”

Distinguish between expired and already-used tokens: “This link has already been used” vs “This link has expired.” Never show generic “Invalid token” errors — map all token states to user-friendly messages (LogRocket, FusionAuth, Postmark).

Rate Limiting UX

OWASP recommends progressive throttling over hard lockouts:

Attempts 1-3: Standard generic error message
Attempts 4-5: Warning: “You have X more attempts before a temporary lockout.” Highlight the magic link resend option.
Attempt 6+: Introduce CAPTCHA. Message: “For your security, please complete this verification.”
After lockout: Clear message with countdown: “Too many attempts. Please try again in 5 minutes, or request a new magic link.” Include a direct recovery link.
Use exponential backoff (1s, 2s, 4s, 8s…) rather than a single long lockout

(OWASP)

Session Expired UX

OWASP recommends 2-5 minute idle timeouts for high-risk data and 15-30 minutes for low-risk. For consumer SaaS apps:

Show a warning modal before expiry: “Your session will expire in 2 minutes. [Extend session] [Sign out]”
On expiry, redirect to login with context: Preserve the URL they were trying to access. After re-auth, return them to that URL. Pre-fill the email field if the identity is known.
For low-risk consumer apps: Use long-lived sessions (days/weeks) with “Remember me” and require re-auth only for sensitive actions (changing email, payment, deleting account)
Never show a raw 401 error page

(Descope, Auth0)

Loading States and Perceived Performance

Auth Page Load Speed

Metric	Impact	Source
1-second delay in page load	-7% conversions	Cloudflare
0.1-second improvement	+10.1% (travel), +8.4% (eCommerce)	NitroPack
Sites loading in 1s vs 5s	3x higher conversion	Portent
Bounce probability: 1s to 3s load	+32% bounce	Google
Mobile >3s load	>50% visits abandoned	Google

Auth pages should load in under 2 seconds. This means: no heavy JS frameworks blocking the form render, no large uncompressed background videos, inline critical CSS, and preload OAuth SDK scripts.

Loading State Patterns

NNGroup established that users transition to a “passive” waiting state after ~1 second, during which they overestimate elapsed time by 36%. Occupied time feels shorter than unoccupied time (Smashing Magazine).

Duration	Recommended Pattern
Under 1 second	No loading indicator. A flash of a spinner is worse than nothing.
1-3 seconds (typical auth round-trip)	Disable submit button, change text to “Sending…” with inline spinner inside the button.
3+ seconds (cold starts)	Full loading state with explanation: “Verifying your credentials…”

After magic link send: Transition immediately to the verify page rather than showing a prolonged loading state. Email sending can happen asynchronously.

After successful auth: Navigate immediately to the dashboard and load user data in the background (optimistic UI).

Skeleton Screens vs Spinners

NNGroup found users perceive skeleton screens as approximately 30% faster than spinners for identical load times. However, auth forms are small, focused interfaces — a skeleton is more useful for the post-auth dashboard than for the auth form itself (NNGroup).

Never use progress bars for auth. Auth round-trips are not deterministic processes with measurable progress. Progress bars would be misleading.

Mobile-Specific Considerations

Mobile vs Desktop Conversion Gap

Metric	Desktop	Mobile	Source
Global conversion rate	3.82-3.99%	1.22-1.32%	Smart Insights
Average screen size	15.6 inches	4.7 inches	Research.com
Password entry time	Baseline	~2x slower	NNGroup / University of Munich

Magic links improved mobile conversion 3x compared to password forms on mobile. Pinterest saw 126% increase on Android (vs 47% on desktop) from Google One Tap, suggesting mobile benefits disproportionately from frictionless auth.

Mobile Auth Guidelines

NNGroup’s mobile-specific findings:

Password entry on mobile takes almost 2x as long as on desktop
Registration should request only the minimum necessary information
Offer social/alternative login methods to leverage existing accounts
Overarching guidance: “Think twice about asking people to register or login on mobile”

(NNGroup)

Tap targets: Minimum 44x44 points (Apple HIG) / 48x48dp (Material Design) for all interactive elements. Apple’s research shows smaller targets result in 25% or higher tap error rates, especially for users with motor impairments.

Keyboard types: Use inputMode="email" for email fields (shows the @ key on mobile keyboards).

Autocomplete: Use autocomplete="email" on the email field. Never set autocomplete="off" on auth forms — modern browsers ignore it anyway. Enable credential manager integration to support autofill and passkeys (MDN).

Accessibility

WCAG Requirements for Auth Forms

The key WCAG success criteria are 1.3.1 (Info and Relationships), 3.3.3 (Error Suggestion), 4.1.2 (Name, Role, Value), and 4.1.3 (Status Messages).

Error announcements:

On error, set aria-invalid="true" on the field. Screen readers announce “invalid” when focused.
Associate error messages via aria-describedby: point the field’s aria-describedby to the id of the error message. Screen readers announce the error text when the field is focused.
Use role="alert" or aria-live="assertive" on dynamically appearing error messages for immediate announcement.
On submit failure, move focus to the first invalid field via HTMLElement.focus().

(Smashing Magazine, WebAIM, W3C WAI)

Keyboard navigation:

Tab order must follow visual order: email field, submit button, secondary links
Ensure the form uses a <form> element with a submit button for Enter-to-submit behaviour
Escape must dismiss modals and return focus to the triggering element
Never set outline: none without an alternative focus style
Test the entire auth flow with keyboard only (Tab, Shift+Tab, Enter, Escape, Space)

(WebAIM)

VoiceOver: Every element needs an accessibility label. Labels should not redundantly include the element type (“Email address” not “Email address text field”).

Colour contrast: Ensure ample contrast between text and background. Do not rely on colour alone to convey error states — always use text and/or icons alongside colour.

Auto-Focus Considerations

Auto-focusing the email field is recommended when the page has “one absolutely unambiguous point of attention” (like a login form). However, screen readers “teleport” users past instructions and headings above the field. On mobile, auto-focus triggers the keyboard, hiding content above the fold.

Recommendation: Keep auto-focus for the login form, but ensure the heading and description are in the DOM before the input, and add aria-describedby linking the input to the description paragraph (Learn UI Design, BOIA).

Accessibility Checklist

Form accessibility:

Requirement	Implementation	WCAG Criterion
All form fields have visible labels	`<label htmlFor="email">` with matching `id`	1.3.1
Error messages use `role="alert"`	Add to dynamically appearing error elements	4.1.3
Invalid fields use `aria-invalid="true"`	Set on input when error is present	3.3.1
Error messages linked via `aria-describedby`	Input’s `aria-describedby` points to error message `id`	3.3.1
Description text linked via `aria-describedby`	Input’s `aria-describedby` also points to description `id`	1.3.1

Keyboard navigation:

Requirement	Test
Tab order follows visual order	Tab through: OAuth button, email field, CTA button, footer links
Enter submits the form	Press Enter in email field triggers form submission
Focus indicator visible on all interactive elements	Tab through all elements; verify visible outline/ring
No focus traps	Tab past the last footer link; focus moves to browser chrome

Loading states:

Requirement	Implementation
Full-page spinner has `role="status"`	`<div role="status" aria-label="Loading">`
Spinner has `sr-only` descriptive text	`<span class="sr-only">Loading...</span>`
Submit button announces state change	Button text changes to “Sending…” which is read by screen readers

Colour contrast:

Requirement	Test
Text on card meets 4.5:1 ratio	Check foreground text against card background
Error text meets 4.5:1 ratio	Check error colour against card background
Muted text meets 4.5:1 ratio	Check muted-foreground — may need adjustment
Footer link text meets 4.5:1 ratio	Check footer text against page background

Tap targets:

Requirement	Minimum Size
All buttons	44x44px (Apple HIG) / 48x48dp (Material Design)
Footer links	44x44px touch target (may need padding)
“Change email” / “Back” text buttons	44x44px touch target

Common Anti-Patterns

What Makes Users Abandon Auth Pages

Cause	Abandonment Rate	Source
Forced account creation	19-26%	Baymard Institute
Login difficulty (general)	87% have abandoned	Frontegg (2025, n=1,003)
Needing to reset a password	42% cart abandonment	Frontegg (2025)
Would switch to competitor with simpler login	52%	Frontegg (2025)
Complex signup forms	83% frustrated	DashClicks
Password creation	67% of registration abandonments	Calendly data
Login friction causing user to stop using site	66%	Frontegg (2025)

(Frontegg)

Specific Anti-Patterns to Avoid

Login walls before value: NNGroup found users are “rarely more annoyed” than when encountering a login wall. Only require login when justified by security or personalisation needs (NNGroup).
Disabling paste on password/email fields: Breaks password manager usability and accessibility. Modern browsers ignore autocomplete="off" anyway.
Generic “Invalid token” errors: Always distinguish expired, already-used, and malformed tokens with specific messaging and recovery actions.
Clearing form fields after errors: Keep user input intact after a failed attempt so they only need to correct what is wrong.
“Sign Up” and “Sign In” used together: The single-letter difference causes confusion. Use “Create Account” / “Sign In” or “Register” / “Log In” instead.
No progress feedback during email send: Users need to see that something is happening within 100ms of clicking the submit button.
Pre-fetched magic links consumed by email scanners: Corporate email security scanners click links before users. Use a confirmation page or multi-use tokens.
Requiring email confirmation links on mobile: NNGroup recommends SMS codes instead to avoid app-switching friction. For magic links, the “Open Gmail” button partially mitigates this.
Over-decorating the auth page: Video backgrounds, animations, and excessive branding that distract from the single task of signing in.
Missing “change email” affordance: If a user typed the wrong email and is stuck on the verify page, they need a clear way to go back.

Conversion Optimization

Benchmarks

The average SaaS signup form conversion rate is 36.2% (visitors who click “Get Started” and complete the form), based on Heap’s analysis of 79 SaaS companies. General SaaS website-to-free-account conversion is 2-5% end-to-end, with top performers exceeding 10% (Heap).

Landing pages with social proof convert 34% better than those without. Displaying reviews can increase conversion by up to 270% (Spiegel Research Center). The optimal range is 3-5 proof elements — more than that triggers “defensive design anxiety” (Flockler, Mouseflow).

Recommendation: Place 2-3 recognisable customer logos or a brief testimonial near the signup form. Position social proof near the CTA button. Use real photos and names for testimonials.

Value Proposition Copy

A clearer value proposition communication achieved a 133.7% increase in new email signups. Removing large blocks of copy resulted in a 26.2% increase. Matching copy to visitor expectations resulted in an 18.67% increase (Invesp, NextAfter).

Recommendation: The auth page heading should answer “What do I get?” in under 8 words. Use a subheading for the specific outcome. Keep copy minimal but benefits-focused. Do not clutter the form area with marketing copy.

Trust Signals

Security badges led to a 12.3% boost in form conversion rates. But over-loading with badges triggers “defensive design anxiety” — one SaaS company saw conversion drop 12% when they added too many (Reform, Crazy Egg).

Recommendation: Add a brief privacy statement near the email field (“We’ll never share your email”). For EU-focused products, a small GDPR compliance note adds trust. Use a single relevant badge near the submit button. Less is more.

Autofill and Credential Manager Impact

Passkeys achieve a 70% increase in sign-in conversion compared to passwords. One-Tap Login achieves over 50% passkey login rates. Proper autocomplete attributes are critical — correct values enable browser credential managers (Corbado).

Priority Actions by Expected Impact

Priority	Action	Expected Impact	Effort
1	Ensure Google OAuth is above email form	+20-40% signups	Medium
2	Single email field (magic link)	+40-60% completion	Medium
3	Auth page load under 2 seconds	+7-10% per second saved	Low-Medium
4	Social proof elements near form	+8-34% conversion	Low
5	Clear value proposition in heading	+18-90% conversion	Low
6	”Get Started” instead of “Sign Up” CTA	Modest but measurable	Trivial
7	Brief privacy statement near email field	+12-15% for trust-sensitive users	Trivial
8	Proper autocomplete attributes	Enables credential managers	Trivial

Bringing It All Together: A Standard Auth Pattern

This section synthesises the research into concrete decisions for every aspect of the authentication experience.

Route Structure

Use a unified flow. Magic links make separate sign-in/sign-up pages unnecessary.

Route	Purpose	Required
`/`	Login page (unified sign-in + sign-up)	Yes
`/auth/verify`	”Check your email” page	Yes
`/auth/error`	Error recovery page	Yes

If migrating from separate pages, add permanent redirects from /auth/sign-in and /auth/sign-up to / for users who have bookmarked the old URLs.

Standard layout (top to bottom):

Full-screen background (video, image, or gradient)
├── Overlay for contrast
├── Centered column (max-w-md)
│   ├── Product logo
│   ├── Product tagline
│   ├── Card (glass, elevated, or filled depending on your design system)
│   │   ├── Heading: "Get Started"
│   │   ├── Description: "Enter your email to sign in or create your free account"
│   │   ├── Google OAuth button (if applicable)
│   │   ├── "or" divider (if OAuth present)
│   │   ├── Email field (single field, no name fields)
│   │   ├── Primary CTA button: "Continue with Email"
│   │   └── Privacy statement: "We'll never share your email"
│   └── Footer links: About, Privacy Policy, Terms of Service

Key decisions:

Decision	Standard	Rationale
OAuth placement	Above email form	Research: +20-40% signups when OAuth is prominent
OAuth button text	”Continue with Google"	"Continue with” is less committal than “Sign in with"
"or” divider	Lowercase “or”, thin horizontal rule	Industry standard; communicates “alternative path” without hierarchy
Heading text	”Get Started”	Outperforms “Sign Up” and “Sign In”
CTA button text	”Continue with Email”	Action-oriented; parallels “Continue with Google”
Name fields	Never during auth	Each field drops conversion 8-50%. Defer to post-auth profile.
Privacy statement	Below CTA: “We’ll never share your email”	+12-15% for trust-sensitive users
Footer links	Always 3: About, Privacy, Terms	Covers legal requirements and builds trust

Verify Page Standard

Feature	Standard
Email display	Show the exact email address the link was sent to
Instructions	Numbered steps: Open inbox, look for email, click link, check spam
Resend button	60-second cooldown timer with visual countdown
Email client deep links	”Open Gmail” / “Open Outlook” / “Open Yahoo” buttons based on domain
Link expiry notice	”This link expires in [duration]“
OAuth fallback	”Or sign in with Google” shown below resend (apps with OAuth only)
Change email	Clear affordance to go back and enter a different email
Layout	Same branded wrapper as the login page for visual consistency

Error Page Standard

All apps must have an error page at /auth/error. The error page must:

Distinguish error types: separate messages for expired, already-used, and invalid tokens
Never show generic “Invalid token” — always show a human-readable message with a recovery action
Pre-fill the email field for one-click resend
Offer a “Send a new link” button
After resend, show the same verify-page instructions for consistency

Standard error messages:

Error Code	Heading	Description
`Verification`	Sign-in Link Expired	This link has expired or was already used. Magic links can only be used once.
`OAuthCallback`	Sign-in Failed	Something went wrong during sign-in. Please request a new link and try again.
`AccessDenied`	Access Denied	You do not have permission to sign in. Please contact support.
`OAuthAccountNotLinked`	OAuth Error	There was a problem signing in with your account. Please try a different method.
`SessionRequired`	Session Expired	Your session has expired. Please sign in again.
Default	Sign-in Error	An error occurred during sign-in. Please request a new link and try again.

Loading States

State	Pattern
Initial auth check (page load)	Full-page centered spinner with `role="status"` and `sr-only` label
Form submission	Inline spinner inside button + “Sending…” text + `disabled` state
After magic link send	Immediate redirect to `/auth/verify?email={email}`
After successful auth	Immediate redirect to the product’s main page

Use a CSS border spinner (no JS import needed) rather than an icon library spinner for the full-page loading state — it renders faster and has zero bundle impact.

Validation

Decision	Value	Rationale
Timing	On blur (per-field) + on submit	”Reward early, punish late” pattern
Error display	Inline below fields	Standard accessible pattern
Empty required fields	Validate on submit, NOT on blur	Do not nag while user is still filling in
`aria-invalid`	Set when error is present	Screen reader announcement
`aria-describedby`	Link to error message AND description	Broadest screen reader support
`role="alert"`	On dynamically appearing errors	Immediate announcement
`autocomplete="email"`	Always on email fields	Enables credential managers

Component Specification

Auth Layout Wrapper

The outermost wrapper that provides the full-screen branded experience for all auth pages (login, verify, error).

interface AuthLayoutWrapperProps {
  children: React.ReactNode;
  videoSrc?: string;
  videoPoster?: string;
  logo: React.ReactNode;
  tagline: string;
  aboutUrl: string;
  aboutLabel: string;
  privacyUrl: string;
  termsUrl: string;
  className?: string;
  cardClassName?: string;
}

Responsibilities:

Full-screen video/image background with dimming overlay
Centered card container with consistent spacing
Footer with About, Privacy, and Terms links
Logo and tagline above the card

Magic Link Form

The core authentication form with optional OAuth integration.

interface MagicLinkFormProps {
  onSubmit: (email: string) => Promise<void>;
  providers?: Array<{
    id: string;
    name: string;
    icon: React.ReactNode;
    onClick: () => void;
  }>;
  heading?: string;
  description?: string;
  submitLabel?: string;
  privacyStatement?: string;
  isLoading?: boolean;
  error?: string;
  defaultEmail?: string;
}

Layout order:

Heading (“Get Started”)
Description (“Enter your email…”)
OAuth buttons (if providers present)
“or” divider (if providers present)
Email field
Primary CTA button
Privacy statement

Key behaviours:

OAuth buttons render above the email form
Submit button shows inline spinner + “Sending…” when isLoading
autocomplete="email" on the email input
aria-invalid + aria-describedby for error states
role="alert" on the error message element
Form submits on Enter

Verify Request Page

The “check your email” page shown after magic link send.

interface VerifyRequestPageProps {
  email: string;
  onResend: (email: string) => Promise<void>;
  onChangeEmail?: () => void;
  linkExpiry?: string;
  oauthFallback?: React.ReactNode;
  productName: string;
}

Features:

Shows the email address the link was sent to
Numbered instructions (open inbox, find email, click link, check spam)
Resend button with 60-second cooldown timer (“Resend in 45s”)
Email client deep link buttons (Gmail, Outlook, Yahoo) based on email domain
Link expiry notice (“This link expires in [duration]”)
Optional OAuth fallback (“Or sign in with Google”)
“Change email” link to return to the login form

Auth Error Page

Error recovery page for failed authentication attempts.

interface AuthErrorPageProps {
  error: string | null;
  email?: string | null;
  onResend?: (email: string) => Promise<void>;
  oauthFallback?: React.ReactNode;
  productName: string;
}

Behaviours:

Maps error codes to user-friendly messages (see error table above)
Pre-fills email field for one-click resend
Shows “Send New Link” button
After resend, transitions to the same verify-page instructions
Supports OAuth fallback for alternative auth

Designing Authentication Pages That Convert: A Research-Backed Guide to Login, Register, and Verify UX

Table of Contents

Unified vs Separate Login/Signup Pages

The Research Consensus

Evidence for Unified (Email-First) Flows

Evidence for Separate Pages

When Each Pattern Works Best

Our Recommendation

Auth Page Layout and Visual Hierarchy

Material Design 3 Recommendations

Apple HIG Recommendations

The Video Background Question

The “OR” Divider Pattern

Magic Link UX

User Understanding

Conversion Data (with caveats)

The “Check Your Email” Page

Email Delivery Speed

Cross-Device Problem

Corporate Email Scanner Problem

Email Deliverability

OAuth and Social Login

Conversion Impact

Placement Best Practice

Google Button Requirements

Apple Sign-In Requirements

Form Fields and Conversion Impact

The Data

When to Collect Name Fields

Text Field Choice

CTA Button Text and Visual Hierarchy

Button Text Research

Button Hierarchy (Material Design 3)

Apple HIG Button Hierarchy

Toggle Link Between Login/Signup

Error Handling and Recovery

Error Message Placement

“Email Not Found” vs “Wrong Password” — Security vs Usability

Expired Magic Link Recovery

Rate Limiting UX

Session Expired UX

Loading States and Perceived Performance

Auth Page Load Speed

Loading State Patterns

Skeleton Screens vs Spinners

Mobile-Specific Considerations

Mobile vs Desktop Conversion Gap

Mobile Auth Guidelines

Accessibility

WCAG Requirements for Auth Forms

Auto-Focus Considerations

Accessibility Checklist

Common Anti-Patterns

What Makes Users Abandon Auth Pages

Specific Anti-Patterns to Avoid

Conversion Optimization

Benchmarks

Social Proof

Value Proposition Copy

Trust Signals

Autofill and Credential Manager Impact

Priority Actions by Expected Impact

Bringing It All Together: A Standard Auth Pattern

Route Structure

Login Page Layout

Verify Page Standard

Error Page Standard

Loading States

Validation

Component Specification

Auth Layout Wrapper

Magic Link Form

Verify Request Page

Auth Error Page

References

Design Systems

Auth Platform Guidelines

Primary UX Research

Magic Link Research

Conversion Optimization