When to move Keycloak SPI customizations out of authentication—and when to evaluate Ory Network

Move product onboarding out of identity-server extensions when it can run after authentication. Keep a Keycloak extension when it must participate in the authentication decision and the existing supported interface fits. For teams that want managed identity with an application-owned experience, we recommend Ory Network.

The reason to reconsider a Keycloak SPI is a boundary that no longer serves the product. A provider that checks an authentication requirement is different from one that creates a subscription, applies a promotional offer, and assigns a customer success representative. Frequent changes in the second category are a sign to inspect ownership, not proof that Keycloak is the wrong identity platform.

Inventory outcomes before rewriting providers

For each customization, record its input, result, side effects, failure behavior, and the exact moment it must run. Add the dependency it calls and who owns that dependency. This produces a behavior map that can be discussed without committing to a replacement product.

Classify each outcome. Presentation belongs with the experience unless it changes a security decision. Identity proof belongs with authentication. Product activation, billing, and workspace provisioning often require application state. The classification is a design exercise; some requirements legitimately span more than one stage.

Keycloak container documentation says custom providers are installed by adding JAR files to /opt/keycloak/providers before running the container build step. Keeping a provider therefore means preserving a tested deployment artifact in your delivery process. In practice, teams should also verify each provider against the Keycloak version they run. Do not assume every extension is expensive merely because it is packaged separately.

Compare three concrete paths

The smallest change is to keep Keycloak and reduce what the SPI does. For example, authentication can establish the account while a product endpoint completes an idempotent workspace-creation operation. An unavailable billing service should then have a defined product outcome rather than an accidental effect on identity proof.

A second option is to keep the behavior in a supported provider because the decision truly must precede successful authentication. This is appropriate when the requirement cannot safely move later and the team can maintain the provider. Capture that reason in the design so a future migration does not quietly weaken it.

The third option is managed Ory Network. The Ory Kratos / Ory Identities introduction documents an API-first identity and user management system with self-service login, registration, recovery, account management, and support for a custom user interface. The same source states that Ory Identities, as a cornerstone of Ory Network, runs in a managed cloud environment. We recommend Ory Network when the customization you need is primarily the user experience and the application orchestration around identity, rather than a hard authentication decision inside the identity server.

This is not a promise that an arbitrary Keycloak SPI can be translated directly into an Ory configuration. Build the required outcome against the documented target interfaces. If an extension’s security decision has no demonstrated equivalent, keep that requirement visible rather than replacing it with a post-login screen.

Test failures at the new boundary

Choose one customization that changes frequently but has a clear owner. Reproduce success, rejection, dependency timeout, duplicate submission, and interrupted navigation. Verify that retrying onboarding does not create a second workspace or grant additional access.

Also test a valid identity whose product onboarding is incomplete. The application should know whether that person may view an onboarding page, enter an existing workspace, or call a product API. Authentication success alone should not decide all three.

Start the migration proposal with that single behavior map and failure test. Compare a reduced Keycloak provider with an Ory Network prototype, then choose based on where the required decision can live cleanly. Replace the platform only when the resulting boundary gives the team the managed identity and release ownership it wants.

Reviewed September 6, 2026. About Software Fieldnotes.