Implementation recipes
These are not feature bullets. They are the guides that ship inside the product, on the Implement tab of each module. Each one carries a goal, prerequisites, the full file inventory, ordered steps with real code, verification at every stage, and a definition of done. Below is what each one covers.
Showing 23 of 173 recipes.
A password change should end every other session, and your tables should hold no credential material. This recipe walks the recovery path — a reset link that expires in an hour, a server-enforced password policy, a confirmation that never reveals whether an address has an account — and leaves both claims demonstrable to a security reviewer.
sessions surviving a password rotation
Let a prospect try the product before creating anything. Guest sessions come from the Better Auth anonymous plugin, gated by an explicit flag on both the interface and the server, so demos work when you want them and with the flags off — the production default — anonymous sign-in is refused outright on both sides.
guest access that cannot leak into production
Support gets a real user directory: search and list accounts, ban an abuser, change a role, or impersonate a user to reproduce a bug exactly as they see it. Better Auth itself denies non-admins, and the admin powers stay separate from the roles your product hands out.
separating support powers from product roles
Some users would rather type six digits than hunt for a link, especially on a shared machine. This adds a code tab to the sign-in page: request a code, type it in, get a full session with no password involved. Codes travel through your existing email pipeline and preview locally without Resend.
codes that work when the link opens elsewhere
Let people sign in with a phone number Firebase has already verified — SMS code, bot check and all — and land them in an ordinary Better Auth session the rest of the app understands, with one user store and one session table. The Firebase Admin SDK stays fenced off where it cannot take sign-in down.
phone verification that cannot run in the isolate
Enterprise buyers who insist on their own identity provider stop being a blocker. Point the app at any standards-compliant OAuth or OpenID Connect provider — Okta, Entra ID, or something homegrown — and their staff sign in through it into ordinary sessions. The provider button only appears once its configuration is complete.
one integration path for any compliant IdP
Visitors on marketing and sign-in pages can be signed in from Google's One Tap prompt instead of a form. When the prompt is dismissed, blocked, or simply unavailable, the standard Google button takes over without an error in sight — and the whole feature stays off until its client id and flags are configured.
clean fallback when the prompt is refused
Add Instagram Business Login beside the providers you already offer. A visitor approves Meta's consent screen and lands on the dashboard as an ordinary account with a stable synthetic email — Instagram never supplies one — plus a stored access token ready for later Graph API calls. Covers the quirks: no discovery document, profile served separately.
a sign-in that hands you no email
Once a product offers several ways in, the sign-in screen becomes a guessing game. This remembers which method succeeded last time and biases the sign-in page toward it on the next visit — the right tab or button already highlighted — so returning users take the same door they used before, no extra configuration needed.
steering returning users to the right method
Nothing to remember and nothing to reset: a one-time email link signs the user straight into a full session. The link goes out through your existing transactional email pipeline and suits consumer products where password friction costs you sign-ups. Sending and accepting are both wired into the existing sign-in page.
single-use links and local preview without Resend
Users can see every device currently signed in from a sessions panel in Settings and cut off the laptop they left behind. Each revoke removes exactly one session, and the browser they are sitting in stays signed in unless they revoke it themselves — no accidental self-logout.
revoking other devices, not the current one
Agencies run each client as its own workspace, with billing, membership and deliverables hard-partitioned per client. Staff jump between clients from the shell without a reload, client contacts join as read-only viewers who can watch delivery in real time, and cross-client access is refused by the server, not just hidden by the interface.
client data isolation proven at the query layer
Seats become a real plan boundary. Invites are refused server-side once an organization uses every seat its plan allows, with pending invitations counted so nobody queues past the cap. The members screen shows seats used against the limit with an upgrade prompt, and support raises a customer's cap without shipping a release.
pending invites counted against the cap
Returning users sign in with the fingerprint or face unlock they already use. Passkeys are registered, listed and removed from account settings, so a lost device can be revoked without touching the account, and on supported browsers the password stops being the daily path.
device support gaps and revoking a lost passkey
Reach users who trust a phone number more than an inbox. Sign-in by text message code works end to end, with codes printed to the console in development so no SMS account is needed, and the same flow switches to a real provider such as Twilio for production.
developing OTP flows without paying per message
Give every member a personal referral link, and credit the right referrer even when the invited person signs up days later or arrives through OAuth. Self-referrals and repeat sign-ups are refused, the referrer sees a live count on their dashboard, and the reward lands as an entitlement change rather than a number in a table.
attribution that survives a delayed signup
Founders leave, teams reshuffle, and the account survives it. Owners promote a successor and step down safely, removals and voluntary departures refuse to touch the last remaining owner, and every governance change is written to the audit log with actor and target, so no path leaves an organization ownerless.
never stranding an org without an owner
Go from an empty deployment to a dashboard where every route demands a live Better Auth session and signed-out visitors are redirected to sign-in. The very first sign-up bootstraps its account and personal workspace in one pass, and you finish by adding a new protected page that proves the pattern.
first sign-in bootstrap, no half-built accounts
Locked-out users get themselves back in through reset links that expire after an hour, and the request page answers identically whether or not an account exists, so recovery cannot probe for registered emails. Reset mail is inspectable locally before Resend is wired up, and unverified accounts are refused by your riskiest actions server-side.
expiring reset tokens and unverified-email refusals
Wallet holders authenticate by signing a message instead of creating another account, ending with a full session on your existing Better Auth setup. Each sign-in uses a fresh nonce, the signature is bound to your domain so a request from elsewhere is worthless, and the option stays hidden until configured.
domain binding that blocks cross-site replay
Google and GitHub sign-in buttons appear only once their credentials are actually configured, so a half-set-up environment never shows a path that fails on click. The OAuth callback lands users in a real session, and first-time arrivals get their account and workspace bootstrapped exactly like password sign-ups.
OAuth arrivals still get a workspace
For accounts where a stolen password would be expensive, add an authenticator-app challenge after the password step. Users enroll from settings, backup codes are issued once for the day the phone disappears, and a lost device becomes a self-service recovery instead of a support ticket.
recovery when the authenticator device is gone
Give people a handle to be known by without making it a second thing to lose. Sign-up accepts a username but never demands one, the profile shows it when present, email stays the recovery key, and a taken name comes back as a readable message rather than a raw error.
uniqueness conflicts surfaced as readable errors