How to Choose a Login Method for Your Indie SaaS

For most indie SaaS products, the best login setup is two options: "Continue with Google" plus an email one-time code (with a sign-in link as a backup), and no password field until customers ask for one. Your buyer decides the details: office teams want Google and Microsoft, developers expect GitHub, and an iOS app with Google sign-in usually needs Sign in with Apple too. Passkeys are a good add-on in 2026, offered after someone signs in, not a replacement on day one. This guide compares each login method by signup friction and support load, covers the duplicate-account traps nobody warns you about, and ends with a 14-day plan and a small sheet to measure it.

Why does the login method matter so much for a small SaaS?

Login is the one screen every customer sees every week for as long as they pay you. When it goes wrong, they do not blame the auth library. They write to you, or they quietly stop coming back. You pay in two currencies:

• Signup friction. Every extra field, rule or inbox trip between "I want to try this" and "I am inside" loses people you never hear from.

• Support load. Password resets, "I never got the link", "the link says expired" and "why do I have two accounts?" are the tickets a login method creates.

You are not choosing the most secure method in the abstract. You are choosing the one your buyers already know how to use, with failure modes you can live with.

What login options do you actually have in 2026?

No row says "no support load". Every method moves the tickets around. The question is which tickets your buyers will create.

Which login method fits your buyer?

Start from what your buyer is already signed in to when they arrive.

• B2B buyers with a work email. Many small companies run on Google Workspace, many larger ones on Microsoft 365. Google and Microsoft buttons let them in with the account their company already manages.

• Developers. For a dev tool, GitHub is the button most people reach for. Add Google for people who keep work and personal accounts apart.

• Consumers on phones. Google and Apple are the accounts already on the device. If you ship an iOS app, read section 4.8 of Apple's App Review Guidelines: an app that uses a third-party or social login such as Google Sign-In for the primary account must also offer an equivalent option that limits data to name and email, lets users keep their email private, and does not collect interactions for advertising without consent. Sign in with Apple is the usual way to meet it, and the section lists exceptions, such as apps that only use your own account system.

• Phone-first staff invited by an owner. Shift workers and contractors often join from a phone, sometimes without a work email. A code they can type is kinder than a link that opens somewhere unexpected.

Before deciding, look at your last 20 signups: how many used a Google domain, how many a Microsoft domain, how many signed up on a phone. That count beats any industry average.

One request to plan for later: a team admin asking for SSO with SAML. It usually arrives with a bigger contract, so treat it as a feature for when a paying team asks, and just make sure your auth setup can add it without a migration.

A running example (made up)

Everything here is invented: the product, the founder and every number. Pebbleroster builds weekly shift rosters for independent cafes and bakeries. The founder, Ines, launched with email and password because it was her framework's default. Owners sign up on a laptop; staff join by invite, almost always on a phone. In four weeks, 212 people start signup, 131 create an account, and 97 complete a first login on a later visit. Her inbox has 18 conversations about getting in: 11 password resets, 4 "your verify email never came", and 3 owners with two accounts. She switches owners to Google plus an email code, switches staff invites to codes, and plans to count again in four weeks.

What goes wrong with magic links and email codes?

Email login removes passwords, which removes reset tickets. It adds a different set of problems, mostly from the inbox, not your code.

• The link opens in the wrong browser. Someone starts on their desktop, opens the email on their phone, and is now signed in on the phone. Or a mail app opens the link in its built-in browser and the session ends up there. To them, login just did not work.

• Corporate scanners click the link first. Supabase's email template docs describe security features such as Safe Links in Microsoft Defender for Office 365 prefetching links, so a single-use link is consumed instantly and the user sees "Token has expired or is invalid". Their suggested fixes: send a one-time code instead, or link to a page with a button that completes the sign-in.

• The email never arrives. If your login emails land in spam, the DEV guide on why your password reset email is probably in spam covers the sender setup; the same fixes apply to codes.

My answer for a small SaaS: put a short code and a link in the same email, and make the link open a page with a "Sign in" button instead of signing in on page load. Keep codes single-use, short-lived (minutes, not hours) and rate-limited, and decide whether an older code still works after "resend". Free email login also attracts junk signups, so watch accounts created against first real logins.

Be honest about strength. NIST's digital identity guidelines, written for US government systems, do not accept email for out-of-band authentication. Email login is still fine for a rota app; it is a convenience choice, as strong as your users' inboxes.

What goes wrong with Google, GitHub and Apple sign-in?

Social sign-in has the lowest friction here. Its problems show up later, in your user table.

• Email as the user ID. Google's guide to verifying the Google ID token on your server says to use the token's sub field as the identifier, because it is unique among Google Accounts and never reused, and not the email, because a Google Account can have different emails over time.

• Treating every "verified" email the same. The same page says Google is authoritative for a gmail.com address, or for a Workspace account where email_verified is true and the hd claim is set. Otherwise, someone may have a Google Account on an email they no longer own, and Google recommends another challenge before you trust it.

• Apple relay addresses. Apple's support page explains that Hide My Email creates a random address at privaterelay.appleid.com that forwards to the real inbox, and only mail from the app's designated senders gets through. Apple's developer help adds that mail from sending domains you did not register bounces. That customer will never sign in with their "real" email, and searching your users for it finds nothing.

How do you stop one person from ending up with two accounts?

A customer who signed up with Google in March types their email into the code box in June. If that creates a second account, they see an empty workspace and assume their data is gone. Prevent it:

1. Store identities separately from users. One user can have several identities: Google, GitHub, Apple, email. The OWASP Authentication Cheat Sheet says to identify a federated identity by issuer plus subject, not subject alone.

2. Link by verified email, with a confirm step. The same cheat sheet says not to link accounts automatically just because the email matches, and to require a signed-in session with the existing account first. In practice: when a Google sign-in arrives for an email that already has an account, send a code to that email, then link.

3. Tell people how they signed up. When someone types an email that belongs to a Google-only account, say "This account uses Continue with Google". OWASP warns that messages revealing whether an account exists help attackers enumerate users, so for products where having an account is sensitive, keep it generic.

4. Email on changes. Send a notice when a sign-in method is linked or removed.

If you keep passwords, what rules should you follow?

If you offer passwords, follow NIST SP 800-63B (revision 4, 2025). It targets government systems, but its password rules are the clearest rulebook around, and they cut tickets too:

• Length, not symbols. At least 15 characters when the password is the only factor; at least 8 when it is only used with multi-factor login. Allow at least 64, including spaces and Unicode.

• No composition rules and no forced rotation. Force a change only when there is evidence of compromise.

• Check a blocklist of common, expected or breached passwords, plus your service name, and say why one was rejected.

• Let password managers work: allow autofill and paste, offer "show password", and skip hints and security questions.

The same section also requires rate-limiting failed attempts and storing passwords salted and hashed with a proper password hashing scheme. If you use an auth provider, confirm it does both.

Where do passkeys fit in 2026?

Add passkeys as an upgrade for people who already have an account, not as the only door. passkeys.dev describes a passkey as a secret stored on the user's devices, unique per service by design, and phishing-resistant because browsers and operating systems only use it for the right service. Its guidance is aimed at sites that already use passwords or one-time codes, which tells you the path: passkeys join an existing login.

The passkeys.dev guide to bootstrapping sign-in on the web gives the pattern:

1. Keep your email field and add webauthn to its autocomplete attribute next to username, so the browser can offer a saved passkey in the field. No passkey? The person continues with your normal method.

2. Offer a passkey after sign-in with another method, or right after account creation.

3. Offer again on a new device if they signed in with a passkey from another one.

Keep the fallback forever. People change phones and borrow laptops, so your email code or social sign-in stays the recovery path.

What default should most indie SaaS ship?

The one answer to copy: Continue with Google plus an email one-time code, with the link in the same email, and passkeys after sign-in once the basics are stable. Then adjust by buyer.

Two or three buttons is plenty. Each extra one is another way to create duplicate accounts.

Should you build login yourself or use an auth provider?

For a solo founder, use something that exists. The options fall into three groups: hosted auth services such as Auth0 or Clerk; auth bundled with your backend platform, such as Supabase Auth or Firebase Authentication; and open-source libraries for your framework, such as Auth.js, where you own the user table. Prices and free tiers change often, so check them the day you decide.

Ask four questions before committing: Can it send email codes, not only links? Can it link several sign-in methods to one user? Can I export my users later, including password hashes? Can it add SSO when a team asks? Build login yourself only when login is your product.

How long should a session last, and do you need "remember me"?

NIST says its lowest assurance level should reauthenticate within at most 30 days. For a typical indie SaaS, a session of a few weeks that renews while someone keeps using the product is a reasonable start. With long sessions you can skip the "remember me" checkbox and add "Sign out of all devices" in settings instead.

Whatever the length, ask for a fresh sign-in before sensitive changes; OWASP recommends requiring current credentials before updating things like the password or email. For a small SaaS that means changing the login email, adding or removing a sign-in method, and deleting the account.

What should you log about logins?

• Log: signup started, method chosen, code or link sent, code verified, link expired or already used, account created, method linked or removed, failed sign-in with a reason.

• Attach: user ID, method, timestamp, desktop or phone.

• Never log: passwords, codes, link tokens or ID tokens.

OWASP also asks you to log and review authentication failures and lockouts. At your size, that means a weekly glance at the count.

How do you know your login method is working?

Track three steps and one ticket count in a small sheet:

"First login completed" means the account came back and got in on a later visit, which is where login problems show up. Tag tickets by reason: reset, never arrived, link expired or used, duplicate account, locked out.

In Ines's made-up case, both counts move the right way and the remaining tickets point at email delivery, not the method. Her numbers are small, so she reads direction, not proof. For the rest of the sheet, see the IndieHunt guide to tracking product metrics before your first 100 users. Once people get in reliably, the next drop-off is the first screen they land on; the EarlyHunt guide on getting new users past the blank prompt box is written for AI tools, but the first-task idea travels.

What traps should you avoid?

• Five social buttons on day one because the provider made it easy.

• Email as the primary key for users.

• Single-use links that sign in on page load, so scanners burn them.

• Password rules that demand symbols and expire every 90 days.

• Passkeys as the only option before your users have any.

• Changing the login method without telling existing users.

• Testing only on your own laptop, signed in to everything.

A 14-day plan to fix your login

1. Days 1 to 2: count signup started, account created and first login completed for the last four weeks; tag a month of login tickets.

2. Day 3: check your last 20 signups by email domain and device; pick two methods from the table.

3. Days 4 to 5: store identities per provider and sub; stop using email as the user ID.

4. Days 6 to 7: email code plus confirm-page link, single-use, short expiry, resend limit.

5. Days 8 to 9: add the social provider your buyers use most, with confirm-then-link for existing emails.

6. Day 10: if you keep passwords, apply the NIST rules.

7. Day 11: session length, "Sign out of all devices", fresh sign-in for sensitive changes.

8. Day 12: add login events, with no secrets in them.

9. Day 13: test on a phone from a mail app, a Microsoft inbox if you can borrow one, and Hide My Email if you offer Apple.

10. Day 14: ship, email existing users one line about what changed, and schedule the four-week recount.

Those day counts are planning guesses for a solo founder using an auth provider, not measurements.

FAQ

Is a magic link more secure than a password?

Not automatically. It removes weak and reused passwords, but it is only as safe as the user's inbox. For most small SaaS products, the real win is fewer reset tickets and less friction.

Should I still offer email and password?

Offer it if buyers keep asking or work somewhere that blocks social sign-in, and follow the NIST rules if you do. Many products launch without it.

Do I need Sign in with Apple?

For a web-only SaaS, only if buyers want it. For an iOS app using Google or another social login for the main account, Apple's guideline 4.8 generally requires an equivalent privacy-focused option; check its exceptions for your case.

When should I add passkeys?

When your main login is stable and "can't get in" tickets are rare. Offer them after sign-in, keep the fallback, and watch how many people accept.

Where should you start this week?

Count your last 20 signups by email domain and device, and tag last month's login tickets. Pick two methods your buyers already use, make sure one person can never end up with two accounts, and measure the three steps for four weeks. If you are getting ready to show the product to new people, a clear listing on IndieHunt brings strangers in, and a login they get through on the first try turns those visits into accounts.