How it works
Onelo runs as one backend that every SDK talks to over the same contract — so you write your integration once and it behaves the same on any stack. You wire it up one of three ways. Here’s how each fits together, and how it’s secured.
The shape
one backend, thin clients- ·holds a
publishablekey (public) - ·signs users in on Onelo’s hosted page
- ·gets a short-lived token + refresh
- ·holds a
secretkey (private) - ·verifies the user’s token with Onelo
- ·never trusts a request on its word
- ·issues & verifies tokens — source of truth
- ·same contract for every platform
- ·flags, monitoring, payments, login
The SDKs are thin clients — the logic lives in Onelo. Swift front with a Node backend talks to Onelo exactly like Python with a JS front. Pick any stack; the wire is the same.
Choose your setup
frontend · backend · bothFrontend only
An app with no server of your own: desktop (macOS/Windows/Electron), mobile (iOS/Android/Flutter/React Native), or a web SPA. It talks to Onelo directly.
- ◆Hosted login — the user types their password on Onelo’s page, never in your UI. You never see the password.
- ◆Device attestation — Onelo verifies the request comes from your genuine, untampered app (App Attest / Play Integrity). This stands in for the missing secret key.
- ◆PKCE — an intercepted login code is useless without the secret your app generated.
- ◆Secure token storage — Keychain (Apple) / EncryptedSharedPreferences (Android), never plain storage.
- ◆Short token + refresh rotation — a stolen token expires fast; a stolen refresh invalidates the session.
- ◆Web: requests are accepted only from the domains you allowlist.
The key point for standalone apps: a frontend has no secret to hide. So Onelo secures it a different way — by proving the app is real (attestation), never exposing credentials (hosted login), and keeping tokens short-lived and safely stored. The publishable key being visible in your binary is fine by design.
Frontend + backend
You run your own server that owns your users’ data/logic and needs to trust that a request comes from a signed-in Onelo user.
- ◆The front signs the user in (as in Setup A) and forwards their token to your server.
- ◆Your backend verifies that token with Onelo using its secret key — it trusts nothing on its word.
- ◆The backend computes nothing itself: Onelo is the source of truth for identity and plan.
- ◆The secret key never leaves your server; the frontend never sees it.
Backend only
A service with no UI — API, worker, cron. “Login” doesn’t exist (there’s no screen). Here “auth” means service authentication, not user authentication.
- ◆The server proves its identity to Onelo with the secret key on every call (plus
client_secret). - ◆You use Features + Monitor. For per-user flags you pass your own user ids (from your auth) to
for_user(). - ◆The secret key lives in the server’s environment — never in your repo, never on a client.
Security primitives
the pieces, and where they applyTwo keys
publishable on the front (public) vs secret on the backend (private). A frontend physically can’t perform server-only operations.
Short-lived token
The user’s access token lives briefly and is refreshed automatically — a stolen one loses validity quickly.
Refresh rotation
The refresh token rotates on every use, with reuse detection — a stolen refresh invalidates the whole session.
Hosted login
front / standaloneSign-in happens on Onelo’s page, not in your UI — you never touch the user’s password.
PKCE
The login code is worthless without a secret generated inside the app — it protects the exchange for a token.
Device attestation
mobile / desktopOnelo checks the request comes from a real, unmodified build of your app.
Origin allowlist
webWeb apps are accepted only from the domains you configure in the dashboard.
client_secret
backend / serverA UI-less server proves itself with an extra secret — in place of Origin/attestation, which it doesn’t have.
Quick matrix
what each setup supports| Module | Frontend only | Backend only | Front + backend |
|---|---|---|---|
| User login | ✓ yeshosted login | ✗ nono UI | ✓ yeson the front |
| Token verification | — n/afront doesn’t verify | ~ dependsonly if a client exists | ✓ yesbackend, secret key |
| Features (flags) | ✓ yes | ✓ yesper-user via for_user() | ✓ yes |
| Monitor (errors) | ✓ yes | ✓ yes | ✓ yes |
| Secured by | publishable + hosted login + attestation / Origin | secret + client_secret | publishable (front) + secret (backend) |