Your apps outliveyour IdP.
SkipAuth wraps the identity provider your organisation already uses, or becomes the provider when there is none. Your applications integrate once, against one issuer. The provider underneath can be swapped, multi-sourced or replaced without a line of application code changing.
- Self-hosted
- your PostgreSQL
- one schema per tenant
- gateway included
Identities
One model · four types| Principal | Type | Status |
|---|---|---|
| [email protected] | HUMAN | Active |
| agent:triage-bot | AGENTtask-scoped | Active |
| svc:billing-sync | SERVICE | Rotation due |
| device:kitchen-tablet-04 | DEVICE | Active |
| [email protected] | HUMAN | Revoked |
Agents, services and devices are marked the same way every time, edge and label, so a directory can be scanned for the rows that are not people without reading a word.Illustrative rows
Your business outgrows its identity provider the way a hermit crab outgrows its shell.
The shell was the right size once. The problem is not the provider, it is that the next one is a migration rather than a decision, because the applications were built against the shell instead of the animal. Three faces of the same problem, and most teams meet all three:
- The integration
- Every application learned the shape of one provider: its claims, its endpoints, its SDK. That shape is now load-bearing in code you do not want to reopen.
- The migration
- An acquisition arrives with Okta, finance standardises on Entra, one team needs Google Workspace. There is no single answer, and the applications cannot hold three.
- The outage
- When the provider is down, everything that outsourced its identity to it is down, and the runbook is a document rather than a capability.
SkipAuth is the animal, not the shell. The identities, the profiles, the roles and the trust graph stay with you.
One contract for your applications.A replaceable provider behind it.
What you actually get when you install it.
One backend process, one gateway, your PostgreSQL and your Redis. No per-user meter, because there is no vendor in the request path.
One issuer per tenant
Each tenant is its own discoverable OIDC issuer and its own SAML identity provider, with its own key set and its own branded sign-in. Onboarding a tenant produces a real identity provider, not a row with a tenant column.
A schema per tenant
Isolation is enforced by PostgreSQL, not by remembering a WHERE clause. Request-scoped context sets the search path per transaction, so a query cannot reach across a tenant boundary by accident.
Federation as the normal case
Microsoft Entra ID, Okta, Auth0, Google Workspace and Keycloak upstream, or local users with a password reset when there is nothing to federate to. One tenant, one active provider, changeable.
Application trust, declared
One client registration and one secret per application. Letting one application call another is adding its audience to a trust list, checked when the token is minted rather than hoped for at runtime.
Machine identities, first class
Service accounts, devices and agents are identity types under the same authorization model as people, with X.509 certificates from a built-in authority and API keys where a certificate is impractical.
Provisioning by role, not by ticket
Put a person in a functional role and the access attached to that role applies everywhere it grants. Take the role away and the access goes with it. No queue, no three-day wait.
Human sign-ins · 24h
2,486
Machine tokens issued · 24h
5,443
Machine share
69%
Who was authenticating, by hour
- People
- Machines
People sign in during working hours. Scheduled agents and service accounts do not stop, and by volume they are the larger population well before anyone decides to govern them.Illustrative figures
An agent is not a userwith an odd-looking address.
Most identity products model a non-human caller as a person who never sleeps and never fails a challenge. SkipAuth gives machines their own type, their own credentials and their own colour, because you should be able to answer what the agents did without filtering a log by naming convention.
Credentials that suit a machine
X.509 certificates from the built-in authority for anything that can hold one, API keys where it cannot, and a service account bound to exactly one application so its outbound trust is the trust of that application.
Delegated tokens with a named audience
When one application acts for a caller, the token it receives says who it may present itself to. The audience is not advice, it is checked when the token is minted and again at the edge.
Roles that end when the task ends
A role can be bound to a task rather than to the identity, so an elevated grant belongs to the work that needed it. The delegated token that carries it names its audience and its expiry, which is what makes the grant something you can account for afterwards.
Most identity products hand you a tokenand wish you luck.
Validating a token in every service is duplication. Doing it once, at the edge, before your code runs, is engineering. SkipAuth ships that edge: a reverse proxy that verifies the signature against a preloaded key, enforces the path rules for the application, manages the browser session, and mints a per-application token from one sign-in so a visitor moving between your applications never sees a second login.
Certificates that renew themselves
Issued, renewed and rotated automatically, scheduled per hostname well ahead of expiry, with domain validation through your DNS provider. Certificate expiry is the most avoidable outage there is, and this takes it off your calendar.
Revocation that reaches every node
A revoked session is broadcast to every gateway instance rather than waiting for a cache to lapse.
Replay costs the whole family
Refresh tokens rotate, and presenting a used one revokes every token descended from it instead of only the one that was replayed.
Three modes, one proxy
Browser applications get a cookie and a redirect, APIs get bearer tokens only, and anything in between gets both.
At the edge, last hour
Before your code ranCertificate renewed automatically
api.northwind.health · valid 89 more days · no ticket, no outage
Directory drift detected
Microsoft Entra ID · a group your roles depend on was renamed upstream
Refresh-token reuse detected
Token family revoked · svc:billing-sync · replay stopped at the edge
Task-scoped role released on completion
agent:triage-bot gave back incident-responder after 4 min 12 s
Illustrative events
Five neighbours, and a plan to build it yourself.Only one is the comparison we would pick.
Which comparison is fair depends entirely on what you are trying to solve, so here is the whole map, including the conversation we would rather you did not have with us.
Identity providers of record
Okta · Auth0 · Microsoft Entra ID
They own the user store, the login experience and the security features around it. Applications end up welded to the claims, flows and SDKs of one vendor.
We do not replace them, and we say so. SkipAuth wraps whichever one you have, so applications hold one client registration against one issuer and the provider underneath becomes configuration.
Identity orchestration
Strata Maverics · SGNL · Aembit
The right category. Sold as enterprise software with pricing on application, with no gateway of its own and no story for giving each of your customers a tenant.
Self-hosted, multi-tenant by database schema, and an edge gateway in the box. An authorization graph too, which the peers in this category leave to whatever sits upstream.
Business SSO brokers
WorkOS · SSOJet · BoxyHQ
One slice, metered per connection: let each of your customers sign in with their own provider.
That slice is a feature here, beside a directory, a role graph, per-resource access and a gateway. No per-connection meter, because you run it.
Self-hostable identity providers
Keycloak · Zitadel · Authentik · FusionAuth
The closest architectural neighbours. Each owns the user store and ships an authorization model you cannot step outside of, and tenancy is a realm or a column.
A schema per tenant, so isolation is enforced by the database rather than by a WHERE clause, and a model built to survive the provider under it being replaced.
Fine-grained authorization
OpenFGA · AuthZed · Permit.io · Oso
A relationship engine you operate as a second cluster, then keep in sync with whatever holds your users.
The same engine already wired to identity, application trust and scopes. The honest limit: they tune check latency at very large scale, and we collapse the integration seam instead.
Assembling it yourself
A proxy, a plugin, a policy engine, a cron job
A reverse proxy with an OIDC plugin, an authorization cluster, a directory sync job and certificate automation is a build that starts every quarter and finishes in none of them.
One deployment, and the parts already know about each other: the gateway reads the same trust graph the token was minted against.
Point one application at itand see what changes.
A walkthrough is a running deployment: a tenant federated to your provider, an application behind the gateway, a role graph with your own shape in it, and an agent holding a token you can watch expire.
The IdP for all AI agents. And humans, too.
Office