Fair objection: Supabase Auth already gets a session working against your Postgres database, and it's good at that. Onelo isn't a database and doesn't compete with Supabase Auth on that job. It's the layer most Supabase-backed apps end up wiring by hand once auth stops being the only problem: 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. | Handled by Onelo's hosted flow, layered on top of your backend. |
| 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. That's the actual point: they're not competing for the same job.
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.