Identity Providers

You keep the identity provider you already run. Apiway does not ask you to migrate directories, re-issue identities, or adopt a second source of truth for who your people are.

Bring your own

Apiway is identity-provider agnostic. Any provider that speaks OIDC and OAuth 2.0 federates, which in practice means the one you already use:

Provider	Federates
Google Workspace	Yes — standard OIDC
Microsoft Entra ID	Yes — standard OIDC
Okta	Yes — standard OIDC
Auth0	Yes — standard OIDC
Keycloak	Yes — standard OIDC
Any other OIDC provider	Yes

The list is illustrative rather than exhaustive. The requirement is the standard, not the vendor — if it publishes an OIDC discovery document and issues tokens, it works.

Tip

The whole of the configuration is client credentials and an OIDC discovery URL. There is no connector to install and no directory synchronisation to schedule. Why there is nothing to synchronise — and what happens when someone leaves — is on When Someone Leaves.

Or use the one that comes with it

Apiway includes an authorisation server. If you have no provider you want to federate — or you are issuing credentials to external consumers and partners rather than to employees — the platform issues and manages them itself: OAuth 2.0 client credentials for machine-to-machine consumers, authorisation code with PKCE for user-facing applications.

Most organisations end up using both: their own provider for employees, and the platform’s authorisation server for the consumers of their APIs, who do not exist in the corporate directory and should not.

What This Covers

Federation applies to the APIs you publish and the people and systems that call them — your workforce reaching your own APIs, your customers’ applications, your partners, and AI agents acting for any of them.

Administering your Apiway tenant through the management console is a separate surface with its own sign-in, and it does not currently federate an arbitrary provider. If that matters to your rollout, raise it — it is a known limitation rather than a design position.

Why agnostic matters beyond convenience

An identity layer you cannot replace is a dependency, not an asset. Because Apiway federates rather than owns, the identity provider underneath stays replaceable — and so does Apiway. A control layer that locked you to one identity vendor would be reproducing the problem it exists to solve.

What this does not change

Whichever provider you federate, enforcement is unchanged: authorisation is applied per operation at the gateway, and the caller’s current entitlements are resolved on every request rather than trusted from the credential. Federation establishes who someone is; what they may do is decided by Apiway when the request arrives. See Security.

See also: Authentication · Scopes · Identity Guard · Deployment Models