Multi-tenant identity
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.
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, and none of them is "spend two quarters building an auth system first." Your developers touch it once; your team runs it from then on.
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, orgs, 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.
What you get
A complete authentication and authorization service your applications reach over one API and four SDKs — plus a control panel your team runs it all from, and webhooks that tell your app the moment access changes. Single sign-on, org hierarchies, roles, encryption, MFA, and a full audit trail. Here is what is in it.
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.
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.
Real-time visibility and granular control over active user sessions and connected devices. Track authorized mobile devices (iOS, Android) and allow users or admins to instantly revoke access remotely directly from the control panel or SDKs.
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.
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.
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.
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.
Each application defines its own permission codes in its own namespace, so two customers can use report.read without colliding.
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.
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.
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.
Spin up disposable tenants to trial the platform or run tests, without touching production data.
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.
A control plane where you manage every customer, and a scoped console you hand to each customer to run their own — same tool, different reach.
Create organizations, nest branches and entities, invite users, issue set-password links, suspend and restore — the whole tenant tree, visually.
Define roles and permissions, register applications, and cut machine-to-machine API clients without a single line of code.
Read the append-only audit trail, and watch usage and consumption per application and per organization — the numbers your billing runs on.
Defence in depth
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.
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.
Measured, not asserted
Verified in the test suite or measured against a million-row
database — including the tests themselves, which we check by
breaking the fix and confirming they fail. Load figures come from
runs whose responses were confirmed to be 200, because
a benchmark counting rejections is measuring the wrong thing.
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.
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 — because tenancy, rotation, revocation, MFA and an audit trail that survives review are each small on their own and enormous together.
// 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, which would be four times the attack surface for no benefit. What they add is that the correct verification is the default and the unsafe shortcuts are unreachable.
The signing keys are discovered from the issuer, not hardcoded, so a moved endpoint never becomes your outage. Keys are 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.
Where we stop
Compliance is a programme, not a feature. Any vendor who tells you their software makes you HIPAA compliant is selling you a sentence you cannot repeat to an auditor.
What we do give you is the technical half, built so that an auditor asking "show me that a customer cannot reach another customer's records" gets a demonstration rather than an assurance.
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.
On Team and Scale the price is the service and support. An application set is one registered audience — a group of services that verify tokens together. Move between plans as you add or retire product lines. 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 is 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 org 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.