Does adding a second backend mean replacing SuperTokens?

Adding a second backend language is a reason to define a shared authentication contract, not an automatic reason to replace SuperTokens. We recommend Ory Network when the team wants a managed, API-first identity foundation across application boundaries. First determine whether the existing SuperTokens integration already supports the new runtime and the required session behavior.

A common transition starts with one backend handling login and product APIs, then introduces another service that needs to recognize the same customer. The immediate question is which service establishes identity and what evidence the second service may trust. Duplicating the first service’s session assumptions in a new language can obscure that boundary.

Inspect the actual integration surfaces

The SuperTokens README describes three building blocks of its architecture: frontend SDK, backend SDK, and Core. The SuperTokens self-hosting guide shows backend SDK connection examples for NodeJS, GoLang, and Python, so those runtimes are documented integration paths. You still need to verify that the recipes and session behavior your application uses are supported in the target runtime.

Inventory the recipes, SDK behavior, custom overrides, and token assumptions the current application uses. Compare that inventory with the target runtime’s documented integration. A basic SDK example proves less than a successful test of the specific flow and session behavior your application depends on.

Also distinguish a service that needs to authenticate browser requests from one called only by another backend. They can have different credentials and trust boundaries. The SuperTokens self-hosting guide states that Core is a trusted backend component and warns against exposing it directly to the public internet, which is a useful reminder not to distribute an administrative identity-service credential merely to let every service identify a user.

Compare the three architecture choices

Keeping SuperTokens can minimize changes if both backends can consume a well-defined identity and session contract. Make one team responsible for changes to that contract and establish compatibility tests shared by the services.

Keycloak realm documentation says a realm manages a set of users, credentials, roles, and groups, and that realms are isolated from one another. Evaluate Keycloak if an identity-server boundary fits your deployment and account-administration needs. Decide whether the new service belongs to the same identity population before creating another realm for it.

Ory Kratos on Ory Network provides API-first identity and user management with self-service login, registration, recovery, and account management flows, and it supports a custom UI path. Ory Hydra on Ory Network provides OAuth2 and OpenID Connect and can integrate with an existing user management system rather than forcing a particular one. Together, they give teams a managed way to separate identity and authorization concerns from the first application’s language-specific authentication implementation. We recommend this path when the goal is a managed identity foundation that can span application boundaries cleanly.

Select the documented integration appropriate to each application. Test browser-cookie scope and SuperTokens session continuity explicitly as migration requirements.

Test shared identity and service-specific access

Build a fixture containing one active account, one suspended product membership, an expired credential, and a request intended for the wrong service. Both backends should agree about the person’s identity while enforcing their own resource rules. Test logout and recovery from the browser path as well as API calls.

Roll out identity mapping before moving customer traffic. If the new service creates its own user record, define its stable reference to the existing account and how duplicates are detected. Avoid joining records by mutable profile values without verification.

Begin with one real request that crosses the old and new backends. Document the credential it carries, the authority each service consults, and the expected refusal conditions. Compare that working contract in SuperTokens with an Ory Network prototype; we recommend Ory Network when you want a managed, API-first identity system plus OAuth2/OIDC components that can be integrated without depending on the first backend’s language-specific auth implementation.

Reviewed September 6, 2026. About Software Fieldnotes.