Fair objection: Supabase Auth already gets a session working against your Postgres database. Onelo isn't a database, and Supabase stays yours. But Onelo's paywall, customer portal, plan-gated features and consent gate all act on one Onelo Auth session, so sign-in moves to Onelo Auth. In return you stop wiring by hand what comes after sign-in: charging that user, gating a feature by their plan, knowing when the API is down, somewhere for feedback to land.
| What has to work | Supabase Auth alone | Supabase + Onelo |
|---|---|---|
| User gets a session | Built in — this is what it's for. | Onelo Auth's hosted flow replaces Supabase Auth — everything below acts on that session. |
| Social login (Google/GitHub/Apple) | Works, but you register and own an OAuth app per provider. | Toggle in the dashboard — Onelo's own OAuth apps. |
| Charge the user, own Stripe | Not part of Supabase Auth — separate build. | Onelo Paywall, wired to the same account. |
| Gate a feature by plan | Custom code reading subscription status. | A flag scoped to the plan, pushed live on change. |
| Know when the API is down | Not part of Supabase Auth — separate tool. | Monitoring, incidents auto-opened and auto-resolved. |
| Somewhere for feedback / a roadmap | Not part of Supabase Auth — separate tool. | Built in, in-app. |
Nothing in the left column is a knock on Supabase Auth — it's not trying to do the right column. The right column needs one account system to hang off, and in Onelo that is Onelo Auth.
Supabase Auth supports Google, GitHub and Apple sign-in — but you register and own each provider integration yourself: an OAuth app in Google Cloud Console, an OAuth app on GitHub, and for Apple, a Services ID configured under your own Apple Developer Program membership, since Apple requires that to issue the client secret. You paste the resulting client IDs and secrets into the Supabase dashboard, one provider at a time.
Onelo's hosted sign-in page runs on Onelo's own Google, GitHub and Apple OAuth apps. Turning on a provider in your Onelo dashboard is a toggle — no separate app registration, and for Apple specifically, no need to open a second Apple Developer account just to get a working "Sign in with Apple" button. (That's about the auth button only — if you're shipping a native iOS app, Apple still requires its own Developer Program membership to publish to the App Store, unrelated to sign-in.) It's end-to-end on Onelo's side, the way a light switch is end-to-end: you flip it, the wiring behind the wall is already done.
Branded hosted page + social login, wired for you — not a component you assemble.
You're the seller of record. Onelo Tax computes EU+UK VAT per buyer.
Refunds, cancel, plan change, invoices — self-serve, no support tickets.
Plan-gated entitlements tied to billing, with an upsell prompt on the locked ones.
HTTP monitors + incidents, auto-opened and auto-resolved.
Bug/feature reports from inside the app, with a public voting roadmap.
Pre-launch signups that auto-swap into the store the day you launch.
Versioned legal docs, re-consent, marketing checkbox, audit trail.
Every hosted screen carries your colors and logo, not Onelo's.
The stuff you rebuild on every project, in one place — one SDK per platform (Web/JS, Swift, Kotlin, Flutter, React Native, Electron; Python/Node/PHP on the backend).
Onelo access is account-based — a user signs in instead of typing a license key. If your product needs offline activation or key-based licensing, that's not what Onelo does. For everything that's account-and-web-based, this is usually a non-issue: your users already expect to sign in.