Login methods explained, and how to test each one

At a glance

Whichever you choose, your app still sends its own emails, such as invites, receipts and notifications. You can check those arrive and link to the right place with any login.

Email and password

The one everyone knows. People choose a password, and if email confirmation is on, they get an email with a link or a code and can’t sign in until they use it.

Emails it sends: a sign-up confirmation, password resets, and an email to confirm a new address when someone changes theirs.

What usually goes wrong:

• Confirmation is off, so anyone can sign up with an address that isn’t theirs, or a typo, and you can never reach them.
• Confirmation is on, but the email never arrives, often because the app still uses the starter email sender from its builder or database, which has low limits. Why emails don’t arrive.
• The link opens localhost or a preview address instead of your published app. How to fix it.
• The password reset link lands on a page with no way to choose a new password.

Test it: sign up with a fresh address and use the link or code. Sign out and back in. Then ask for a password reset and finish it. Step by step.

Email codes

People type their email, get a short code (often 6 digits) and type it in. There’s no password to remember. Some apps also use a code to confirm sign-up: Base44 and Clerk both do.

Emails it sends: a new code every time someone signs in.

What usually goes wrong:

• The code expires before the email arrives.
• Asking for a second code doesn’t cancel the first, or cancels both.
• Someone who asks twice gets “too many requests” and is locked out.

Test it: ask for a code and use it. Ask for two in a row and check that only the newest works. Proxy Mail QA shows a countdown when the email says how long the code lasts. More on testing codes.

Magic links

People type their email and click the link you send them. One click, no password.

Emails it sends: a new link every time someone signs in.

What usually goes wrong:

• The link opens localhost instead of your app.
• The link fails in a different browser, or on a phone where the mail app opens its own browser.
• Email security scanners at some workplaces open links before the person does, which uses them up.

Test it: ask for a link and open it in the same browser, then try it on another device. Check that a used or expired link explains what to do. Proxy Mail QA never opens or prefetches links, so yours is still fresh when you click it. More on magic links.

Google, Apple, Microsoft and GitHub buttons

People click Continue with Google (or Apple, Microsoft or GitHub) and pick their account. Your app never handles a password, which is why AI app builders add these so readily.

Emails it sends: none to sign in. The provider handles it.

What usually goes wrong:

• It works in the preview but fails on your published app or custom domain. The new address isn’t on the provider’s list of allowed redirects, and Google shows redirect_uri_mismatch.
• The sign-in screen shows your builder’s name, not your app’s. Lovable and Base44 both offer a shared setup that works straight away. Switch to your own credentials before launch if that matters to you.
• Someone signs up with email and password, then later clicks Continue with Google with the same address. Decide whether that should be one account or an error, and test it.
• Sign in with Apple can hide people’s email. Your app gets an address ending in privaterelay.appleid.com, and your emails only reach the person if you’ve registered your sending domain with Apple.

Test it: these buttons need a real account, so use a Google or Apple account you own, on the published app as well as the preview.

Phone codes

People type their phone number and get a code by text message. It needs an SMS provider such as Twilio, and each text costs money. Proxy Mail QA receives email only, so it can’t help here.

Company sign-in (SSO)

For apps sold to businesses: staff sign in through their employer’s login, such as Okta or Microsoft Entra ID, usually over a standard called SAML. Lovable and Base44 both support it. It sends no email to sign in, but team invites usually still go by email.

Signing in with the builder’s own account

Some builders let people sign in with an account on the builder itself. With Replit Auth, your users sign in with a Replit account on a Replit-branded page, and Replit sends the emails, such as password resets. Lovable offers Sign in with Lovable too. That suits internal tools and apps for other builders. For a public app you’ll usually want your own accounts: on Replit, that’s Clerk Auth.

What should a new app use?

For most apps: email plus Google.

• Google is the quickest sign-up for most people.
• Email covers everyone else: people without Google, people using a work address, and anyone who’d rather not link their account.
• Prefer codes or magic links if you don’t want passwords. Codes work better when people read email on their phone but use your app on a laptop.
• Keep email confirmation on, and send email from your own domain before you launch.

Which login does your builder set up?

Login services coding agents use

When you build with a coding agent, it wires your app to a login service. Each sends different emails, and each has one thing that breaks them most often: