Sign in with Apple, phone codes and two-step sign-in, now on BuildBase

BuildBase sign-in now goes well past a password and a Google button. An app can offer Sign in with Apple, a code by text message, a second step from an authenticator app, an Ethereum or Solana wallet, and a code typed on a phone to sign in a TV or a command line tool. None of it needs a line of new code in your app.

That last sentence is the design. So before the list, the reason.

One call, and the page decides

Your app has one signIn(). It sends the person to the sign-in page BuildBase hosts for you, and that page shows the methods ticked on the app they came from. Add Apple in the console, tick it on your customer app, and the button appears. Leave it off your staff app and it does not.

We could have shipped a signInWithApple() and a signInWithPhone(). Each new method would then have been a release you had to adopt: a dependency bump, a code review, a redeploy. Instead a method is a row in the console. Its setup guide is written for whoever on your team holds the Apple Developer account or the Twilio login, who is often not the person who writes the React.

What is new

New sign-in methods.

• Sign in with Apple. Four values from your Apple Developer account and the button is on your page. What bites later is the name Apple sends only once, and mail to Apple's relay addresses. The Apple setup guide covers both.
• One OpenID Connect or OAuth 2.0 provider of your own, such as Keycloak or your company's identity provider, as one more button.
• Email sign-in codes, beside magic links. A code can be typed on any device, which rescues the person who asks for a link on a laptop and opens the email on their phone.
• SMS sign-in codes through your own provider: a text message, a WhatsApp message or a voice call, sent with your own Twilio account or your own signed webhook.
• Crypto wallet sign-in with an Ethereum or Solana wallet.

New ways to use them. These are not methods of their own, so they sit apart from the list above.

• Google One Tap, a setting on the Google method.
• Sign-in with a username for people who would rather not type an email address.
• Guest users, who keep everything when they add an email later.
• Device code sign-in for CLIs and TVs, approved on a phone or computer.

Around the sign-in.

• Two-step sign-in with an authenticator app, single-use backup codes or text-message codes, under a policy of off, optional or required. An authenticator app or a passkey is the stronger choice, and a passkey sign-in that checked a fingerprint, a face or a PIN already counts as both steps.
• Who may sign up: an allowlist, a blocklist or a waitlist you approve, with Cloudflare Turnstile to keep scripts off the sign-up form.
• A breached-password check on sign-up, reset and change.
• Trusted devices. A device someone trusts stays signed in longer, and the Devices screen lists every device they are signed in on, to rename or sign out.
• Account screens in the SDK. The Security screen covers the password, a phone number, two-step sign-in, connected accounts, passkeys and deleting the account.

Moving in. User import from Clerk, Auth0, Firebase and Supabase. Password hashes and social sign-ins come across too, so nobody has to reset a password on the day you switch.

The page itself. The hosted sign-in page in 8 languages (English, Spanish, French, German, Japanese, Chinese, Hindi and Arabic), branded per app.

One more, kept apart on purpose. It is not a way for a person to sign in. Every app is an OAuth 2.0 authorization server, so AI agents and third-party apps register, ask a signed-in user for access on a consent screen, and get a token that user can revoke. That is the half a remote MCP server does not do for itself: it validates tokens, it does not issue them.

Why phone codes go through your provider

This is the decision people ask about, so here it is plainly.

BuildBase sends no SMS of its own. The codes leave through your Twilio account or your webhook, at your provider's price, under your provider's fraud settings. A paid BuildBase plan bills over its allowance only for workflow runs, web analytics events and storage, so there is no per-message line on our invoice either.

The reason is the attack that comes with every phone number field. Scripts ask sign-in pages to text codes to premium-rate numbers, and someone takes a cut of what the sender pays. Twilio calls it SMS pumping. The first fix is choosing which countries can receive a code at all, and that switch already lives in your Twilio account, next to the bill it protects.

It keeps the price honest too. Twilio Verify charges $0.05 per successful verification on top of the message itself, which is $0.0083 for a text to a US number. A plain text is about a sixth of that. Which one you want depends on whether you would rather Twilio made and checked the codes. The phone setup guide covers both, plus a webhook for any other provider.

What it means if you already use BuildBase

Nothing changes until you tick something. The methods you offer today keep working, and no app shows a button you did not add.

To add one, open Authentication in the console, add the method on the Methods tab, then tick it on the app in its Edit sheet. Some methods need a plan that includes them, and the pricing page has the current plans. There is a step-by-step guide per method, with screenshots, starting at docs.buildbase.app/sign-in-setup.

If you built your own account settings page, the SDK's Security screen now covers two-step sign-in, a phone number and connected accounts. Open it from your own button with openWorkspaceSettings('security'), and delete the code you no longer need.

What is not changing

Sessions. Still 30 days by default, and signing out still ends the session on the server.

Pricing. There is a Free plan at $0, then Launch at $19 a month and Grow at $49, and the paid plans start with a 7-day trial that does not ask for a card. Active users are an allowance on each plan, not a meter, and the new methods did not add one.

What is not on every plan. Enterprise SSO (SAML and OIDC) is on the Enterprise plan only, through your own WorkOS account. If an enterprise customer's IT team needs to plug in their identity provider, our WorkOS comparison is honest about where that leaves you. And the SDK is still web-first: the framework guides cover Next.js, Vite, React Router, TanStack Start, Express, NestJS, Fastify, Hono and Astro.

The existing guides. Passkeys, magic links and social login still describe how those methods work. None of them needs a route handler in your app, and neither do the new ones.

Sources

Twilio figures verified 17 October 2026 on Twilio's own pages: Verify pricing ($0.05 per successful verification, plus $0.0083 per SMS to a US number) and preventing SMS pumping and toll fraud. BuildBase facts come from the same plans, module catalog and session defaults that drive /pricing and /auth.