Multi-tenant SSO & authorization API
Every multi-tenant system promises isolation. Most of them enforce it in application code, which protects exactly the paths someone remembered to protect. We enforce it three times, and the innermost layer does not care whether your developers remembered.
115 isolation tests · 9,700 rps sustained · verified against 1,000,000 organizations
The business case
Building login, users, and permissions in-house quietly eats quarters and ships no revenue on its own. Buying it turns a project into a line item, and, at the top tier, into a product you can resell under your own name.
Get to market without spending a team on plumbing, then open a new line by white-labeling the same platform to your own customers. And "do you support SSO?" stops being the question that loses you enterprise deals.
Building this in-house is months of senior engineering plus maintenance that never ends. This is one predictable subscription instead, priced by the applications you register, not per user, so growth does not punish you.
Tenant isolation, encryption, MFA, and an audit trail you can demonstrate to an auditor: the controls a security review asks for, already built and running, not a line on a roadmap.
How it works: three steps, none of them "spend two quarters building an auth system first."
Your app calls the service through an SDK, live in an afternoon, with no authentication code for you to own or maintain.
Your team runs customers, users, roles, and API keys from the control panel: the admin tooling you would otherwise have to build yourself.
Add product lines as you expand, or resell the whole platform white-labeled to your own customers, each fully isolated, on a dedicated deployment.
Switching providers
Migrating identity providers is where projects stall: nobody wants to re-create thousands of users, companies, and roles by hand, or make everyone reset their password. Import your whole estate in one validated pass: passwords carried over, nothing written until it checks out.
Export your organizations, users, roles, and permissions into one file, or our CSV templates. Records link by your own ids, so nothing has to be renumbered.
A dry-run finds every problem: a bad email, a duplicate, a missing link, and reports the exact row and field up front. Nothing is written yet.
Provisioned in one transaction. bcrypt passwords carry over verbatim; anyone without one gets a set-password link. Idempotent, so a re-run never duplicates.
Passwords come with you · validated before anything is written · safe to re-run · no engineers required, fill a spreadsheet in the console, or call the bulk-import API.
Coming from another provider? → Migration guides in the docs ↗
What you get
A complete authentication and authorization service reached over one API and four SDKs, with a control panel your team runs it all from. The seven capabilities below are the ones that decide a purchase; everything else the platform does is listed underneath.
Nothing assumes a single company at the top. On your own dedicated deployment, your platform account provisions as many independent tenants as you like, each with its own subtree of branches, entities, and users, and each fully isolated from the rest. That is what makes white-labeling straightforward: a platform can resell the same product to its own customers, giving each one its own organization tree, roles, and login, without any of them ever seeing another. On a shared plan you still get one tenant with sub-organizations beneath it, isolated by role reach.
One identity across your entire ecosystem. Users log in once, while dedicated app-identifiers scope and authorize entire microservice clusters behind them. Whether running 3 distinct apps or 3 massive enterprise ecosystems, identity remains unified while audience boundaries stay strictly enforced.
The same boundary enforced independently in the service and in the database with row-level security, plus schema constraints. Neither layer alone is the security boundary.
Compose roles from each application's own permission vocabulary. Change a role and the current tokens of everyone who holds it are invalidated: revoked access never lingers.
Personal data encrypted at rest with rotatable keys, still searchable through a keyed blind index. A data-subject erasure request scrubs it while keeping stable internal ids, and notifies your apps.
Append-only in the schema. Records who did what to whom, every role change, erasure, and refused attempt to reach another tenant, in a human-readable log.
The instant a user's access changes (a role assigned or revoked, its permissions edited, an account disabled or erased) your app is told, so you can clear caches instead of waiting for the next failed request. HMAC-signed, replay-protected, retried.
Model your customer's real hierarchy: company, entity, branch, department, any depth, and delegate administration down the tree with self and subtree scopes, without an admin ever seeing a sibling's data.
Each application defines its own permission codes in its own namespace, so two customers can use report.read without colliding.
Your API verifies each token itself and never calls us on the request path. Signature, issuer, audience, purpose: four checks, and the audience check has no off switch.
Sign in with Google or Microsoft, verified for you: the audience claim is checked against your client id and a verified email is required before linking. Fail-closed, closing the classic OIDC confused-deputy hole.
TOTP with recovery codes, account lockout, and refresh-token rotation with reuse detection. Backend jobs authenticate with OAuth2 client credentials, kept strictly apart from user tokens.
Every login is a named, trackable device: model, platform, last active. Users see every device signed in and revoke any one of them; you see it too, for support and for the audit trail. Web sessions hold the refresh token in an httpOnly cookie, unreachable by XSS.
Real-time visibility and control over active sessions and connected devices. Track authorized mobile devices (iOS, Android) and revoke access remotely from the control panel or SDKs.
Spin up disposable tenants to trial the platform or run tests, without touching production data.
Migrating a front end built against another identity provider? Add your own claim names, including a roles array for the active company, alongside ours. The standard claims stay exactly as they are, so nothing that already verifies a token has to change.
Your own applications can raise their own alerts into the same feed as ours: a failed payment, low stock, anything you want an operator to see. One toggle per application, authenticated with the client_credentials token it already has; no new integration to build.
Critical alerts push to the Regulated plan's native mobile app the instant they fire. Assign one to whoever owns it, or leave it unclaimed for the first responder to grab: either way it drops off everyone else's queue in real time, with a resolution note once it's handled.
Password-reset and account mail goes out under your own product name and from-address, not ours, so a user resetting their password never has to wonder whose email just landed in their inbox.
client_credentialsYour apps call the API and get RSA-signed tokens back, then verify each one locally against the published JWKS, so we are never on your request path, and a slow moment on our side never becomes a slow moment on yours.
The control panel
The API is for your developers. The control panel is for everyone else, so no one has to build an internal admin tool. Create a customer, invite a user, define a role, register an application, cut an API key, read the audit trail, watch usage. Every capability the service has, by clicking. And on the Regulated plan, a native mobile app carries the part that can't wait when you're away from the desk: security alerts, pushed the moment they fire.
Brute-force lockouts, token theft, MFA disabled on a privileged role: pushed to a native app the moment they fire, with enough control on screen to act: disable a user, clear the alert, check who did what. Your own applications' custom alerts land in the same feed, the same way.
Defence in depth, measured
These are numbered because the order is real. Each one catches a different kind of mistake, and the later layers exist precisely because the earlier ones depend on human diligence. The figures below are measured against a real 1,000,000-row database and verified by the test suite, not asserted.
Holding a permission says nothing about which customer it applies to. Every request carrying an organization id is checked against the scopes the caller was actually granted, and a token with no scope is refused rather than trusted. It fails closed.
Layer 1 protects the paths that call it. A repository method added
next year, a query built from a string, an endpoint that skips the
service: none of those are covered. So the database enforces the
same boundary itself: a query arriving without a tenant context
returns nothing, not everything.
Composite foreign keys mean a row's tenant cannot disagree with the
record it came from. Database triggers derive each node's position
in the customer hierarchy, so it cannot be written incorrectly. The
audit trail refuses UPDATE and DELETE
outright, not in code, in the schema.
Integration tests against a real database, not an emulated one.
Reads against 1,000,000 organizations, 500 concurrent clients, 45 ms median.
From disabling an account to its live tokens being refused, with no per-request database lookup.
Index scan, unchanged by how deep a customer nests.
What buying this doesn't give you: a Business Associate Agreement with your hosting provider, a documented risk assessment and a designated security officer, an incident-response plan, a third-party penetration test, and deciding who gets administrative access in the first place. Compliance is a programme, not a feature: this is the technical half an auditor can be shown, not the paperwork half.
Security & data residency
The service runs in a single region and data does not leave it. Production hosting is chosen per client, Hetzner, DigitalOcean, or AWS, DigitalOcean by default for US clients. Production access is scoped, individually credentialed, and logged; our engineering team is distributed and works under the same controls we sell. A BAA and DPA are available on the Regulated plan.
Official SDKs
Identity is the part of a build that looks like two weeks on the plan and turns into two quarters in the repository. Not because signing a token is hard: it's because tenancy, rotation, revocation, MFA and an audit trail that survives review are each small on their own and enormous together.
composer require latchvector/sso
pip install latchvector-sso
npm install @latchvector/sso
com.latchvector:latchvector-sso-spring-boot-starter
// Express: the whole integration const verifier = new TokenVerifier({ issuer, audience }); app.get('/invoices', requireAuth(verifier), (req, res) => { res.json(invoices.forOwner(req.principal.uid)); });
# FastAPI: the whole integration auth = SsoAuth(TokenVerifier(issuer=..., audience=...)) @app.get("/invoices") def list_invoices(user: Principal = Depends(auth.required)): return invoices.for_owner(user.uid)
// Laravel: the whole integration Route::get('/invoices', [InvoiceController::class, 'index']) ->middleware('sso.auth'); Route::post('/invoices/{id}/approve', ...) ->middleware(['sso.auth', 'sso.can:invoice.approve']);
# Spring Boot: the whole integration latchvector.sso.issuer: https://sso.yourdomain.com latchvector.sso.audience: https://api.yourcompany.com // then, in any controller @GetMapping("/invoices") List<Invoice> list(Principal caller) { return invoices.findByOwner(caller.uid()); }
Token verification, login + MFA, refresh rotation, machine-to-machine, and one-call webhook verify.
Dependency and middleware integrations for each, with the same full feature set.
Laravel middleware, a Symfony integration, and a plain client that drops into any framework, plus webhook verify.
An auto-configuring starter, resource-server wiring, and JPA multitenancy helpers.
Signature, issuer, audience, and token purpose. No SDK exposes a switch to turn any of them off. The audience check is the one that matters: a token minted for a different application is validly signed by a trusted issuer, so a signature check alone accepts it, and with it, every user of every other application on the platform.
The SDKs wrap each ecosystem's established library rather than reimplementing RSA in four languages. Signing keys are discovered from the issuer, not hardcoded, and cached in memory: your API verifies locally and never calls us on the request path.
Refresh tokens rotate on every use, and presenting a rotated one is reported as the compromise it probably is, as a distinct error type your retry logic cannot silently swallow.
Pricing
You pay for the applications you register, each set of services with its own audience and permissions, not per user and not per tenant. A customer that grows from ten seats to ten thousand costs you the same; a second product line is what moves you up a plan.
For a single product with a few backend services behind it.
For a platform with several product lines, each its own set of services.
For HIPAA or financial data, where isolation and paperwork are part of the product.
Move between plans as you add or retire product lines, nothing to migrate, just a plan change. At the Regulated tier the price follows isolation: a dedicated instance, or a database for a single customer, costs more to run than a shared deployment, and that's the conversation to have.
Book a demo
Choose a free time below and you get a working walkthrough: the isolation tests run live, the audit trail, the SDK dropped into a real service. Not a slide deck, and it starts on time.
Prefer email? Write to us and we'll find a time.
The four-level company chart, the shared email address across two legal entities, the auditor who wants to see refused access attempts. Those are the conversations we would rather have early.
Tell us what you are building. A real engineer reads every request and answers, usually within a day.