Sign-in options compared: email codes, magic links, passwords, Google
How email codes, magic links, passwords and Sign in with Google work, what current NIST and OWASP guidance says about each, and which combination suits a new app.
Key Takeaways
- Most new apps do well with two options. A one-time email code for everyone, plus Sign in with Google (or Microsoft for work tools). That covers people who live in Gmail and people who don’t, with no passwords to store.
- Passwords are still fine if you follow current rules. NIST’s SP 800-63B revision 4 sets a 15-character minimum for single-factor passwords (8 if used with another factor), allows at least 64 characters, bans composition rules and routine forced resets, and requires checking new passwords against breached lists.
- Email codes and magic links rely on the inbox. Anyone who controls the email account controls the app account. NIST’s revision 4 says email shall not be used as an out-of-band authenticator at its assurance levels, which is worth knowing if you handle sensitive data.
- With Google, store the sub claim, not the email. Google says the sub value is unique and never reused, while a Google Account’s email can change. Verify the ID token’s signature, audience, issuer and expiry on the server.
- Rate limits and identical error messages matter more than the method. OWASP recommends the same response whether the account exists or not, and limiting failed attempts per account. These apply to every option here.
Quick-Start Prioritization Framework
| Method | Best for | Friction | Main risk |
|---|---|---|---|
| Email one-time code | Most consumer and small-business apps | Low: type 6 digits | Inbox compromise; delayed email |
| Magic link | Apps used mostly on one device | Low on the same device, awkward across devices | Inbox compromise; link opened on another device |
| Email and password | Users who expect it; offline-ish habits | Medium: create, remember, reset | Reused and breached passwords |
| Sign in with Google | Consumer apps, Google Workspace users | Lowest for Google users | Depends on Google account; account-linking edge cases |
| Passkeys (add-on) | Returning users on modern devices | Low after setup | Recovery when devices are lost |
The sign-in screen is the first thing every user touches and the part of an app most often copied from a tutorial without much thought. The choice matters: it decides how many people finish signing up, how many support emails you get about lost access, and how exposed accounts are to password reuse and phishing. This guide compares the four methods most new apps offer, explains how each one works behind the button, and ends with a recommendation for typical apps built with AI tools.
What any sign-in method has to do
Whatever the button says, the backend does the same three things: confirm the person controls something (an inbox, a password, a Google account, a device), create or find the matching user record, and issue a session so they stay signed in.
Authentication, then a session
The method only covers the first step. After it, most apps set a secure, HTTP-only session cookie. Session length is a separate decision: 30 days is common for consumer apps; admin tools often use shorter sessions.
Account recovery is part of the method
Every method needs a way back in. For passwords, it is a reset email. For email codes and magic links, the method is the recovery. For Google, it is Google’s own recovery. For passkeys, it is usually a fallback such as an email code. A method is only as strong as its recovery path.
Email one-time codes
The user types their email, receives a short code, and types it back. No password is ever created.
How it works
The server generates a random code, stores a hash of it with an expiry, and emails it. When the user submits the code, the server compares, checks the expiry, and marks the code used. Supabase’s defaults are a typical reference point: a six-digit code, valid for one hour, with one request allowed every 60 seconds; it discourages expiry settings longer than a day.
Strengths
Nothing to remember and nothing to leak in a password breach. It works across devices: request the code on a laptop, read it on a phone. Sign-up and sign-in are the same flow, which simplifies the screen.
Weaknesses
Security equals the security of the inbox. Every sign-in depends on email arriving within seconds, so you need a reliable sending service and a verified domain. NIST SP 800-63B revision 4 says email shall not be used for out-of-band authentication, citing risks such as inboxes protected only by a password and interception; that guidance is written for US federal systems, but it is a useful signal if your app holds sensitive data.
Magic links
A magic link is the same idea as an email code, delivered as a clickable URL with a one-time token. Supabase notes that its magic links and email codes share one implementation; only the email content differs.
Where links shine
On a phone or laptop where the user reads email in the same browser, one tap signs them in. There is nothing to type.
Where links get awkward
If someone requests a link on a laptop but opens the email on a phone, the link signs in the phone, not the laptop. Some flows also require the link to open in the same browser that requested it. A code avoids both problems, which is why many apps send the link and a code in the same email.
Make links one-time and short-lived
Treat a link like a password that expires: single use, short validity, and invalidated once a newer one is sent. Log the sign-in so users can see recent sessions.
Email and password
Passwords are familiar and work without email delivery at sign-in time. They also bring the most responsibility for the app builder.
What current guidance says
NIST SP 800-63B revision 4 sets these rules for verifiers: at least 15 characters when the password is the only factor, or at least 8 when it is part of multi-factor sign-in; accept at least 64 characters; don’t impose composition rules such as “one number and one symbol”; don’t force periodic changes, only changes after evidence of compromise; and reject passwords found on lists of common or breached values. OWASP’s Authentication Cheat Sheet repeats these and adds: don’t silently truncate, allow spaces and Unicode.
What you must build
Store passwords only as slow, salted hashes using a library built for it. Build a reset flow by email. Limit failed attempts per account, not just per IP address, as OWASP recommends, so attackers can’t rotate addresses. Return the same message for a wrong email and a wrong password.
When passwords are the right call
Some audiences expect them, for example users of shared office computers who don’t want to open email to sign in, or markets where email delivery is slow. Offering a password plus an email-code fallback is a reasonable middle ground.
Sign in with Google (and other providers)
Social sign-in hands authentication to an identity provider. Google’s web library offers a personalised button, One Tap and automatic sign-in for returning users, and returns an ID token your server uses to sign the user in.
Verify the token on the server
Google’s documentation lists the checks: the token is properly signed by Google, its aud value matches one of your app’s client IDs, its iss is accounts.google.com or https://accounts.google.com, and its expiry hasn’t passed. Use Google’s client libraries rather than hand-rolling this.
Use sub as the identifier
Google says the sub field is unique among all Google Accounts and never reused, and warns against using email as the identifier because an account’s email can change. Store sub on your user record and look users up by it.
Microsoft, Apple and others
Microsoft sign-in matters for tools sold to businesses on Microsoft 365. Apple sign-in matters most for iOS apps. Each provider adds a developer console, redirect URLs per environment and its own token rules, so add only the ones your users actually ask for.
Where passkeys fit
Passkeys replace a typed secret with a key pair stored on the user’s devices and unlocked with a fingerprint, face or device PIN. The site keeps only a public key, and the browser or operating system makes sure a passkey is used only with the site it was created for, which is what makes them resistant to phishing, according to passkeys.dev, a site from members of the FIDO Alliance and a W3C community group.
For a new app, passkeys work best as an upgrade offered after first sign-in, with an email code as the fallback for new devices.
Side-by-side comparison
Ratings are relative to each other for a typical consumer or small-business web app.
| Email code | Magic link | Password | ||
|---|---|---|---|---|
| Sign-up steps | Email, code | Email, click | Email, password, often confirm email | One or two taps |
| Works across devices | Yes | Partly | Yes | Yes |
| Needs email at every sign-in | Yes | Yes | No (only for resets) | No |
| Secrets you store | Short-lived code hashes | Short-lived token hashes | Password hashes | None (store sub) |
| Biggest support issue | Email in spam or delayed | Opened on wrong device | Forgotten passwords | Signed up with a different method before |
| Setup work | Email service and domain | Email service and domain | Hashing, reset flow, rate limits | Google Cloud project, client ID, redirect URLs |
A sensible default for a new app
For most apps built with ChatGPT, Claude, Codex or Cursor, start with an email code plus Google. Add Microsoft if you sell to businesses. Offer passwords only if your users ask. Then decide one rule up front: if someone signs in with Google using an email that already has an account, do you link them or ask them to sign in the original way first? Linking only when the provider says the email is verified is a common, safe choice.
Prompt you can give an agent
“Add sign-in with a six-digit email code that expires in 10 minutes and Sign in with Google. Store Google’s sub, not the email, as the Google identifier. Link a Google sign-in to an existing account only if Google marks the email verified. Rate-limit code requests to one a minute per address. Show the same message whether or not an account exists.”
Common mistakes
These are the sign-in bugs that show up in production most often.
Telling attackers which emails exist
“No account with that email” on the sign-in form lets anyone check whether a person uses your app. OWASP recommends identical messages, status codes and response times whether the user exists or not, including on sign-up and password reset.
No rate limits on codes
A six-digit code has a million combinations. Without a cap on attempts per code and per account, it can be guessed. Lock the code after a handful of wrong tries and require a new one.
Duplicate accounts for one person
The same person signs up with an email code in March and with Google in May and ends up with two empty accounts. Decide your linking rule before launch.
Redirect URLs only set for localhost
Google sign-in works in development and fails on the real domain because the production redirect URL was never added. Test sign-in on the production domain before you announce the launch.
If you’d rather not build sign-in yourself
If you’d rather not build these flows yourself, Floot apps come with their own sign-up and login by email, Google or Microsoft, with roles, and your users don’t need a ChatGPT or Claude account to use them.
Frequently Asked Questions
Are magic links more secure than passwords?
They remove password reuse and breached-password risk, which are common causes of account takeover. They move the risk to the email account instead. For most consumer apps that is a good trade; for sensitive data, add a second factor.
How long should an email sign-in code be valid?
Short. Supabase defaults to one hour and discourages anything over a day; many apps use 10 to 15 minutes. Make each code single-use and invalidate it when a new one is sent.
Do I still need to force users to change passwords every 90 days?
No. NIST SP 800-63B revision 4 says verifiers should not require periodic changes and should force a change only when there is evidence of compromise.
Should I use the user’s Google email as their ID?
No. Google’s docs say to use the sub claim, which is unique and never reused, because a Google Account’s email address can change.
Is SMS a good second factor?
NIST classes phone-based codes as a restricted authenticator, citing risks such as SIM swaps and number porting, and requires offering alternatives. Authenticator apps or passkeys are stronger choices.
Can I offer more than one sign-in method?
Yes, and most apps should offer two. Just decide how accounts are linked when the same email appears through different methods.
Sources
- NIST, SP 800-63B-4 Authentication and Authenticator Management, 2025 https://pages.nist.gov/800-63-4/sp800-63b.html
- OWASP, Authentication Cheat Sheet, 2026 https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
- Supabase, Passwordless email logins, 2026 https://supabase.com/docs/guides/auth/auth-email-passwordless
- Google for Developers, Sign in with Google for Web overview, 2026 https://developers.google.com/identity/gsi/web/guides/overview
- Google for Developers, Verify the Google ID token on your server side, 2026 https://developers.google.com/identity/gsi/web/guides/verify-google-id-token
- passkeys.dev, What are passkeys?, 2026 https://passkeys.dev/docs/intro/what-are-passkeys/