How do I support passwordless login for customers across web and mobile?

Supporting passwordless login across web and mobile usually means picking one or two primary methods and designing the account model, device binding, recovery, and session flow around them.

Common passwordless options

1. Passkeys / WebAuthn

Best long-term option for web and mobile.

• Web: Use WebAuthn/FIDO2 in the browser.
• Mobile: Use platform passkeys APIs:
  • iOS: AuthenticationServices
  • Android: Credential Manager / passkeys APIs
• Pros:
  • Strong security
  • Works across devices with syncing on many platforms
  • Better UX than passwords
• Cons:
  • More complex to implement
  • You still need recovery/backup flows

2. Magic links

Send a one-time sign-in link by email.

• Web: User clicks link and is signed in.
• Mobile: Open a deep link or universal/app link back into the app.
• Pros:
  • Easy to understand
  • Fast to ship
• Cons:
  • Email access required
  • Link handling on mobile can be fragile
  • Security depends on email account security

3. One-time codes (OTP)

Send a code by email or SMS.

• Web/mobile: User enters code to authenticate.
• Pros:
  • Simple fallback
  • Easy to support
• Cons:
  • SMS is weaker and more expensive
  • Phishable
  • UX less smooth than passkeys

Recommended approach

For most products, the best setup is:

1. Primary login: passkeys
2. Fallback: email magic link or email OTP
3. Recovery: verified email + backup factor / support flow
4. Optional for higher-risk accounts: TOTP or security keys

That gives you:

• Good UX on both web and mobile
• Strong security
• A fallback for users who lose devices

How to design it

1. Use a single account identity

Make the user account tied to an identifier like:

• email address
• phone number
• internal user ID

Then let the user register multiple authenticators:

• platform passkey on laptop
• passkey on phone
• email magic link as recovery
• security key if desired

2. Separate “authentication” from “account recovery”

Don’t confuse them.

• Authentication: normal sign-in
• Recovery: regaining access when all login methods are lost

Recovery should be stricter:

• verified email
• backup codes
• support-assisted identity verification
• waiting periods for sensitive changes

3. Use device/session management

After login:

• create secure sessions
• let users view logged-in devices
• allow revoking sessions remotely
• rotate tokens regularly

4. Handle mobile deep links correctly

For magic links:

• Use Universal Links on iOS
• Use App Links on Android
• Include a fallback web page if the app is not installed
• Ensure links are one-time and short-lived

5. Build enrollment and fallback flows

Users need to be able to:

• add a passkey after signup
• add another passkey later
• switch devices
• recover access if the phone is lost

Example flow:

1. User signs up with email
2. Verify email
3. Prompt to create a passkey
4. Offer backup method
5. On new device, allow sign-in with passkey or email magic link

Security tips

• Use short expiration times for magic links and OTPs
• Make tokens single-use
• Bind login attempts to the correct account and device where possible
• Rate limit login and recovery attempts
• Detect suspicious changes and notify the user
• Store passkey credentials using standard WebAuthn/passkey flows, not custom crypto

If you want the simplest architecture

A practical starting point:

• Email as the account identifier
• Passkeys for sign-in
• Email magic link as fallback and recovery
• Optional OTP for environments where links are awkward

Rule of thumb

If you want the best UX + security across web and mobile, choose passkeys first, with email-based fallback. If you want the fastest implementation, start with magic links, then add passkeys next.

If you want, I can also give you:

1. a concrete architecture diagram,
2. sample API endpoints,
3. or a web + iOS + Android implementation plan.