Almost every identity integration is written against a specific provider. Not on purpose: it happens because the provider is what was in front of you when you wrote it. Its discovery document, its claim names, its group format, its SDK, its quirk about email_verified. None of that is unreasonable on the day. It becomes unreasonable the day somebody asks what it would take to move.

SkipAuth is the thing your applications integrate with instead. It is a real OIDC authorization server and a real SAML identity provider, per tenant, with its own discovery document and its own signing keys. Behind it, it federates to whatever your organisation actually runs.

What this means concretely

An application registers once. It gets a client identifier, a secret, and a discovery address that looks like every other OIDC discovery address:

GET /t/{tenant}/.well-known/openid-configuration

From then on, the application knows nothing about Microsoft Entra ID, Okta, Auth0, Google Workspace or Keycloak. It knows one issuer. The upstream provider is a row in the tenant registry with credentials attached, configured through the admin console, and changing it is an administrative act rather than an engineering project.

The parts of identity that would normally be lost in a move are the parts that live here:

Identities and their links. An identity is keyed in SkipAuth, and the provider-native identifier is a link record beside it. The same person can carry the same SkipAuth identity across a move from Okta to Entra ID, because the thing your data references was never the Okta identifier.
Profiles. Custom attributes, defined per namespace with their own schemas, are yours. No provider needs to agree to hold them.
Roles, functional roles and their scopes. The whole authorization model sits above the provider and does not care which one is underneath.
The application trust graph. Which application may mint a token for which is a SkipAuth concern, so it survives too.

How to check it

Do the swap in a test tenant, in this order, and watch what you have to touch:

Federate the tenant to provider A. Sign in to a demonstration application.
Note the identity that was created, its profile attributes, and its role memberships.
Change the tenant to provider B in the admin console.
Sign in as the same person. The identity is the same record with a second provider link, the profile is unchanged, and the roles still resolve.
Count the application deployments required. It should be zero.

The interesting number in step five is the one to hold every vendor in this category to, including us.

Where it stops

Federation is over OIDC. The upstream connectors are Microsoft Entra ID (including delegated and application-only token modes, and photo retrieval through Microsoft Graph), Okta, Auth0, Google Workspace with optional domain enforcement, and Keycloak with a configurable realm. SkipAuth is a SAML identity provider to your applications; it federates upward over OIDC, which is what every provider in that list speaks.

One active provider per tenant. A tenant federates to one upstream at a time. Mixed estates are handled by giving each population its own tenant, not by chaining several providers behind one issuer. That is a deliberate choice: one tenant, one answer to the question of where a person actually lives.

Security features belong to the provider that owns the credential. Factors, conditional access and risk signals are enforced by the upstream, because it is the upstream that holds the password and sees the device. SkipAuth does not sit between a person and their own provider's challenge, and it should not want to. What travels into your applications is the outcome, in one token shape, from one issuer.

What the alternatives ask of you

Approach	What it asks of you	SkipAuth
Integrate applications directly with the provider	Nothing today. On the day you move, a change in every application, every test suite and every environment.	One registration against one issuer, and a configuration change in the tenant when the provider changes.
A provider that also brokers, such as Keycloak in broker mode	Adopt its user store and its authorization model, which you cannot step outside of, and its realm shape.	Your model stays yours: identities, profiles, roles and trust are SkipAuth records above the provider.
An enterprise orchestration product	Licence per application or per identity, run it as a service you do not control, and bring your own gateway.	Self-hosted, in your infrastructure, with the gateway in the box.
Write an abstraction layer in house	A translation layer, a directory, a token service and the tests for all three, maintained forever.	The layer already exists, along with the parts nobody remembers to scope.

Read next: a schema per tenant, not a tenant column, which is what makes giving a population its own tenant a cheap decision rather than an architectural one.