Request
Fill in the form and we provision a temporary organization — a tenant with the full platform behind it: SSO, organizations, roles, webhooks, audit trail. No card required, and no production data in it.
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 capabilities below are the ones that decide a purchase; everything else the platform does is listed underneath, and the plan boundaries are in the table at the end of the section.
Model the hierarchy your customer actually has — company, entity, branch, department, as deep as it goes — and delegate administration down it with self and subtree scopes, so an admin never sees a sibling's data. Nothing in the schema assumes a single company at the top.
On Regulated, that tree stops being one company's: your account provisions independent tenants, each node can carry its own brand and login, and a subtree can be hidden from the parent that provisioned it. That is what makes reselling the same product to your own customers straightforward. On Team and Scale you get one tenant with sub-organizations at any depth, isolated by role reach.
Every plan Regulated plan
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 — so a platform can resell the same product to its own customers without any of them ever seeing another.
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. On Regulated, each node of the tree carries its own brand, so a reseller's customers see the reseller.
Which plan includes what
| Capability | Team | Scale | Regulated |
|---|---|---|---|
| Application sets | 1 | Up to 3 | Unlimited |
| Sub-organizations at any depth | Yes | Yes | Yes |
| Isolation in the database (row-level security) | Yes | Yes | Yes |
| Delegated admins, self and subtree scopes | Yes | Yes | Yes |
| All SDKs, full REST API, local token verification | Yes | Yes | Yes |
| Append-only audit trail, MFA, webhooks | Yes | Yes | Yes |
| Mobile device authorization | Yes | Yes | Yes |
| DPA / AVV, signed | Yes | Yes | Yes |
| Priority support with a response-time target | No | Yes | Yes |
| White-labeling and branding per node | No | No | Yes |
| Independent tenants on one account | No | No | Yes |
| Subtree hidden from its own parent | No | No | Yes |
| Native mobile app for security alerts | No | No | Yes |
| Signed BAA | No | No | Yes |
| Dedicated instance or single-customer database | No | No | Yes |
| Data residency choice and contractual SLA | No | No | Yes |
| Custom token claims and assignable alarms | No | No | Yes |
Anyone handling US protected health information should be looking at Regulated: that is the plan a BAA is signed on. Full prices are on the pricing page.
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. EU production defaults to Germany, on Hetzner; US production defaults to DigitalOcean US; other regions on request. The sandbox runs in Germany, on netcup. Production access is scoped, individually credentialed and logged; our engineering team is distributed and works under the same controls we sell. A DPA (AVV) is signed on every plan, and a BAA is available on Regulated.
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
The four packages above are the ones we publish and support. They are a convenience, not a requirement: verification is a local JWT check against a JWKS endpoint, so any stack that can do that works — .NET, Go, Ruby, Elixir — with no call to us on the request path. The token format, the claims and the JWKS URL are documented, and we will walk your team through a first verifier in whatever language you are in. Token and JWKS reference ↗
// 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. Team and Scale carry a list price, Regulated is quoted against the isolation you need, and a DPA / AVV is signed on all three.
30-day sandbox
Three steps, no card, and nothing your developers do during the trial is thrown away if you carry on. The sandbox runs in Germany, on netcup.
Fill in the form and we provision a temporary organization — a tenant with the full platform behind it: SSO, organizations, roles, webhooks, audit trail. No card required, and no production data in it.
Your developers integrate against the sandbox for 30 days, using any of the SDKs or the REST API directly. Same endpoints, same tokens, same control panel as production.
Choose a plan and we convert the temporary organization into a permanent sandbox, so your team keeps its integration work, and we open production access according to your plan — Team, Scale or Regulated.
By default the temporary organization and its data are deleted when the trial ends. If you continue, we make it permanent so your developers keep their work.
Yes, by agreement. Talk to us before it expires and we will sort it out.
Germany, on netcup. EU production runs in Germany too, on Hetzner.
Agreed per customer as part of onboarding. Your integration work and the sandbox itself stay; what moves across from a trial tenant into a production one is something we settle with you rather than promise in advance.
Yes. Every Regulated capability can be switched on for a trial, white-labeling and per-node branding included, so you can see it working before you commit to it. What gets enabled is agreed with you when we provision the sandbox — tell us what you need to evaluate and we set it up that way.
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.