Auth lock-in and portability: what should IAM teams evaluate?

TL;DR: Auth-as-a-service lock-in is real but uneven, with the biggest risks sitting in data portability, API standards, SDK coupling, and pricing gates that can make migration painful even when user data is exportable, according to Clerk's guide. The practical test is whether teams can leave with users, hashes, sessions, and standard OIDC flows intact, because portability is an operational control, not a marketing claim.

Editorial analysis by NHI Mgmt Group, based on content published by Clerk: “What Is Auth-as-a-Service? The Complete Guide - Part 3”.

Key questions

Q: How should teams evaluate auth-as-a-service providers for lock-in risk?

A: Evaluate portability in four areas: data export, API standards, SDK coupling, and pricing or contract friction.

Q: Why do standard identity protocols reduce migration risk?

A: They keep the application's identity layer decoupled from one provider's implementation.

Q: What breaks when password hashes cannot be exported?

A: The receiving provider cannot preserve user credentials, so teams lose the ability to move users without resets or trickle migration.

Practitioner guidance

• Define portability requirements up front Require full user export, password-hash export, metadata export, and documented migration-out steps in vendor evaluation and contract review.
• Standardise on open identity protocols Build authentication around OIDC discovery, standard claims, and JWKS validation so application code is not tied to one vendor's token surface.
• Contain SDK coupling behind a facade Route provider-specific logic through a thin auth abstraction so sign-in UI, session checks, and route guards can change without broad rewrites.

Bottom line: Auth-as-a-service lock-in is best understood as an exit-risk problem across data, APIs, code, and commercial terms.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →