Buy vs build CIAM
The instinct to build customer identity in-house fades fast. Teams that wrote their own years ago tend to find it harder every year to keep pace with new attacks, new standards, and new regulation. The realistic question is not build-or-buy as a clean binary, it is how far up the stack you buy and how much assembly you accept on top.
Why building the core is rarely worth it
The one area to avoid building yourself is the protocol layer. Implementing OAuth and OpenID Connect without opening security holes is a full-time specialty, because both are frameworks with many extensions and the security best practices keep moving. Unless identity is your core business, license or adopt open source for the core and spend your engineering on the experience layer that differentiates you.
Three positions on the spectrum
- Core protocols, you build the rest: the platform gives you the standards (SAML, OAuth, OIDC) and APIs, and you build most of the customer-facing flows. This fits teams with real identity skills and a large user base who want to minimize license cost and expect to replace vendor UI anyway. Open-source platforms and lighter cloud primitives sit here.
- APIs plus configurable UI: a fuller set of APIs with some out-of-the-box screens. The middle road for teams that do not want to reinvent the wheel but still want control.
- More complete out of the box: richer configurable journeys, consent management, and marketing integrations ready to switch on. Less to build, but even here some integration and custom UI is normal.
The market map shows where platforms fall, and the pricing guide covers how the position you choose changes cost.
Buying still means building
Even a complete platform leaves work: custom UI over the registration and profile APIs, SDK integration into your mobile app, and integrations with marketing, CRM, and support tools. Plan to iterate on every customer-facing screen after launch, because the configurable defaults rarely optimize the experience fully. Involve your developers in selection so development-oriented requirements are weighed early and the team does not quietly start a parallel build.
What to ask a CIAM vendor
- Which core protocols are supported natively, so we never implement OAuth or OIDC ourselves?
- How much of the registration, profile, and recovery experience is API-driven vs fixed UI?
- What is the realistic integration effort for our marketing, CRM, and mobile stack?
- Where does the platform sit on the build-vs-configure spectrum, and does that match our engineering capacity?
- What ongoing work should we budget after launch to tune the customer journey?
The buyer takeaway: almost no one should build the identity core, and almost everyone who buys still builds the experience around it, so size the assembly honestly against your team before you choose a position on the spectrum. One concrete fork on that spectrum is headless versus hosted CIAM. Match it to your capacity, then run the vendor matcher.