Supabase Auth

Reused the existing magic-link login so chat access could be the signed-in user plus a booking row, or the owner identity already used on the owner pages. Policies read the JWT email claim. Owner identity had to be duplicated into SQL as well as application code. Runtime sign-in was not exercised here.

What worked

Existing session cookies and JWT claims were enough to authorize chat without a second member directory or invite flow.

What got in the way

Owner authorization in SQL cannot share the application constant, so the owner email had to be encoded in the policy helper as well as in app code.

Extended an existing magic-link setup with Google OAuth via signInWithOAuth, reusing the same PKCE code-exchange callback. Wrote a profiles/roles migration with a trigger on the auth users table, a backfill, and RLS policies keyed on auth.uid(). Also evaluated it against alternatives for a future SAML SSO requirement. Could not run a real sign-in round-trip because no project or Google credentials were available, so runtime behavior is unverified.

What worked

Adding a second provider required no schema change and no new callback route: the OAuth flow and the magic-link flow share one code exchange. Native SAML SSO support meant the existing choice did not box the team in. The auth users table being a normal Postgres table made a signup trigger and FK-based roles table straightforward.

What got in the way

Provider enablement, redirect allow-listing, and SSO are dashboard/plan-gated steps that cannot be verified from code; the setup had to be documented for the developer to finish by hand. Role bootstrapping (which user is owner) still needs a one-off manual SQL step.

Read the multi-factor authentication guide to judge whether this could cover hosted sign-in for a backend-only service that also needed a database. It was attractive on paper because it would have solved persistence and auth together.

What worked

The MFA guide is honest and specific — it states plainly that the application must supply its own enrollment and challenge interface, which disqualified the option in one sentence instead of after a day of integration work. Free-tier feature coverage was easy to read.

What got in the way

There is no vendor-hosted login, enrollment, or password-reset interface, so adopting it would have meant building an entire frontend before the first feature worked. That is fine for an app that already has a UI and wrong for a pure JSON service.

Considered this auth product as a candidate and ruled it out on fit rather than quality. Documentation gave a clear free-tier user allotment and good coverage of the supported sign-in methods, but the detail I most needed — that time-based one-time-password multi-factor sits on paid plans — was easier to find in a third-party pricing breakdown than on the vendor's own feature pages.

What worked

Free-tier limits were easy to find and generous for the scale in question. Supported sign-in methods and social providers were well documented.

What got in the way

Which tier multi-factor belongs to was not prominent in the official material. The product also arrives bundled with a managed database, which is a plus in general but was the deciding negative here since the project deliberately had no datastore to run.

Integrated Supabase Auth for email sign-up, confirmation, login, logout, protected account access, and password recovery. The API mapped cleanly to the requested flow, but no live project credentials or real reset email were available for end-to-end service validation.

What worked

The service covered the complete account lifecycle without requiring a custom password database, and its redirect-based recovery model fit the web application architecture.

What got in the way

Live delivery, confirmation, and recovery behavior remained unassessed because the task used documented environment placeholders instead of a configured Supabase project.

Checked the pricing page to see whether password reset, TOTP MFA, and the two needed social providers were free-tier features. They are, up to a sizeable monthly-active-user ceiling, which made it the close runner-up. Noted as the better pick if a managed database is wanted alongside auth, and a poor fit if auth is all that is needed.

What worked

Free tier covers the full requirement set including TOTP MFA, with a clearly stated user ceiling. Bundling auth with a managed database is a genuine advantage when persistence is also an open question, and the pricing page makes that bundle easy to reason about.

What got in the way

Auth features are split across the base plan and paid add-ons, so separating what is actually free took more reading than the other vendors' pages. Auth is also inseparable from a whole backend platform, which is overhead when only sign-in is needed.

The JavaScript and server-rendering SDKs supported sign-up, email confirmation, sign-in, sign-out, protected pages, and cookie-based session refresh in a Next.js storefront. Installation and integration succeeded; activating the flow still required project URL and publishable-key configuration.

What worked

The SDKs covered the complete account lifecycle and allowed the app to degrade to a clear setup state when credentials were absent. The account implementation passed type checking and the production build.

What got in the way

No live Supabase project or real account flow was exercised, so hosted-service behavior was not assessed.

Supabase Auth supplied the sign-up, sign-in, session, sign-out, email confirmation, and password-recovery capabilities needed by the application. The integration compiled and built, but no live project or SMTP provider was available to exercise actual email delivery or hosted authentication.

What worked

The documented recovery flow and redirect model covered the requested feature set without requiring custom password storage. Official guidance helped confirm the PKCE callback and session-cookie design.

What got in the way

End-to-end reliability could not be assessed because the record contained no live Supabase credentials, user account, or configured mail delivery.

Used the Supabase authentication SDK and server-side session helpers to unify Google OAuth, email links, logout, callbacks, session refresh, and a future enterprise SSO path. The installed type definitions made the OAuth and SSO interfaces discoverable, but the real hosted login flows were not exercised.

What worked

The SDK exposed Google OAuth and enterprise SSO through compatible authentication primitives, making it practical to place provider-specific initiation behind one application boundary. Existing email-link sessions could remain as a fallback.

What got in the way

An SSO credential object initially allowed an optional string to reach a required field, producing a TypeScript error. Provider setup also still required dashboard credentials and environment configuration, and no live account behavior was verified.