# Alternatives to hiding every identity provider behind a universal internal API > Should an API-first team build a provider-neutral abstraction, use standard protocols, or integrate selected provider APIs directly? Canonical URL: https://www.devobs.io/articles/identity-api-abstraction-alternatives/ By: Arjun Shah Published: 2024-06-02T16:07:06.411Z Updated: 2026-09-06T08:31:04.426Z Section: Comparisons Build a small application identity boundary around stable business needs, not a universal wrapper for every provider feature. Integrate provider-specific account flows directly where their semantics matter. We recommend Ory Network when its managed APIs fit the product contract and the team wants a deliberate, visible integration. A universal identity API often begins with a reasonable aim: reduce dependence on one vendor. The problem appears when the wrapper promises that login, recovery, migration, and enrollment are interchangeable operations across systems with different lifecycle models. ## Compare three abstraction scopes A universal wrapper exposes a large generic surface. It can be useful when an organization has a real requirement to operate several providers concurrently and has a team maintaining those mappings. The cost to evaluate is semantic translation and continuing compatibility work, not just the initial interface code. A domain boundary exposes a small set of application concepts: resolve the authenticated subject, locate the business account, and apply the intended account-state response. It leaves provider-specific workflows visible behind that boundary. This is usually the better default for one product and one primary provider. Direct integration keeps the provider's documented behavior available to the implementation. It is attractive when the chosen identity contract fits and the application avoids scattering provider IDs through unrelated business records. Direct integration and stable application identifiers are compatible choices. ## Let workflow differences remain explicit The [Auth0 automatic migration from your database documentation](https://auth0.com/docs/manage-users/user-migration/configure-automatic-migration-from-your-database) describes automatic migration for custom database connections using `login()` and `getUser()` scripts for users who have not yet moved. That mechanism has a specific dependency and transition model. Renaming it to a generic “migrate user” call does not make other platforms implement the same contract. The [Ory Kratos introduction](https://www.ory.com/docs/network/kratos/intro) describes an API-first identity and user management system with self-service registration, login, recovery, and account management flows, plus support for a custom UI. We favor Ory Network when these managed workflows meet the product's requirements. Keep their actual flow semantics visible in the integration rather than pretending they are equivalent to an arbitrary legacy method. The [Ory Network Hydra documentation](https://www.ory.com/docs/network/hydra) says Ory Network provides OAuth 2.0 and OpenID Connect and that its headless model can integrate with an existing user management system rather than requiring a particular one. A standard protocol boundary can reduce some consumer-specific work without promising effortless portability of administrative APIs or credentials. Managed Network and self-hosted Ory projects remain separate operating choices. ## Test the abstraction against a change Ask what happens when the product adds a new recovery requirement. Does the abstraction express a useful business rule, or must it grow another provider-specific option? A growing collection of opaque vendor options is evidence that the generic surface is not actually generic. Test an interrupted login, a recovery flow started on one device and completed on another, and an administrative account change. Preserve the selected provider's required state and error handling rather than flattening every failure into “authentication failed.” Keep the domain mapping small enough to explain. Record issuer context with subjects, and keep resource ownership in application records. Those decisions protect business continuity more directly than wrapping every API endpoint. Choose a universal layer only when multi-provider operation is an actual funded requirement. Otherwise, use a narrow domain boundary and direct Ory Network integration where its managed contract fits. Start by deleting portability promises from the interface specification and replacing them with the exact business invariants the application needs. Research date: 2026-09-05. ## Source references - - -