Most companies don’t actually know who their users are. They know they have accounts. They know those accounts can log in. What they usually can’t answer is the harder identity question: what can this specific person access right now, and who else holds that same level of access?
That question stays easy to dodge for a long time. Most engineering teams ship auth the same way at the start. A users table, a bcrypt hash, a session cookie, a password reset email. For one app with a few hundred users, that’s fine. It’s the right call, even. The problem is that “auth” doesn’t stay that small, and the design that was correct on day one quietly turns into the thing you spend the next three years paying for.
By the time anyone notices, it’s expensive. Identity has stopped being a login form and become a distributed systems problem with your security posture, your compliance story, and half your operational overhead all hanging off it.
This is an argument for centralizing identity behind a real identity provider. But I’m not going to pretend it’s free or obvious, because it isn’t, and any engineer who’s done a migration knows it. So we’ll go through what actually breaks, why the protocols matter, and the cases where rolling your own is still a reasonable bet.
What Identity Sprawl Actually Is
People hear “identity sprawl” and picture too many login screens. That’s the cosmetic version. The real problem is that every system grows its own idea of what a user is, and none of those ideas agree.
The portal keys users on email. The internal tool keys them on an employee ID synced from HR. The support platform spins up a fresh account the first time someone files a ticket. E-commerce has its own customer record entirely. Same human, four systems, four primary keys, no join. When you eventually need to ask “everything this person can touch,” there’s no query that answers it. You’re fuzzy-matching on email and hoping.
Underneath that, the credential stores diverge too. Some hold password hashes. Some half-federate against a directory. Some have a service account with a static API key that got committed to a config file in 2021 and nobody remembers. Your real attack surface is all of them stacked together, and it’s only as strong as the laziest one in the pile.
Here’s the test that exposes how bad identity management has gotten. Pick a name. Can you list every system that person can log into, and every permission they hold, in five minutes, and actually trust the answer? In a fragmented shop the answer is no, and that gap is exactly where incidents come from.
How this Becomes a Breach
Identity shows up in breach post-mortems over and over, and the failure modes are boring and predictable, which is the frustrating part.
Offboarding is the classic. When removing someone’s identity means a manual checklist across a dozen systems, the odds that all twelve get done correctly drop fast. The ones that bite are the accounts nobody watches: service accounts, API tokens, SSH keys, CI credentials tied to a person who left in March. They never show up in your “active users” view and they don’t expire on their own. They just sit there.
Then there’s the credential problem. Make people manage separate passwords and they’ll reuse them, so one breached store becomes a stuffing list for all the others, and with no central place to detect it you find out the slow way. MFA doesn’t save you either if the coverage is partial. You can lock the front door and still lose, because the legacy app accepts username and password against the same directory, or an API endpoint doing basic auth skips the interactive flow entirely. Attackers go around. Partial MFA against a real adversary is closer to no MFA than to full coverage.
And then permissions just accumulate. Someone changes teams, picks up new access, never loses the old. Do that for a few years and people are walking around with entitlements that have nothing to do with their current job, which means every compromised identity has a blast radius far bigger than it should. You can’t run a real access review on this because the entitlement data lives in fifteen places.
When the auditor shows up wanting to know who accessed what, when, and under what authorization, you get to reconstruct it from logs in five formats with no shared identifier. SOC 2, ISO 27001, HIPAA, PCI, GDPR, they all want some version of that evidence. Assembling it after the fact costs far more than it would have to emit it cleanly from one place to begin with.
Consolidation Is Where the Bill Comes Due
If you want to see identity debt in its full glory, watch a platform consolidation. Here’s the shape it usually takes. A company acquires another business. Both sides have a customer portal, a support system, and an e-commerce platform, so now there are accounts for the same customers sitting in six different stores. Leadership scopes the merge as mostly frontend work, some shared navigation, a unified login, a bit of integration glue. Six months in, the thing that’s actually blocking the launch isn’t design and it isn’t the integrations. It’s that nobody can reliably determine which accounts across those six systems belong to the same human being.
That’s the real work, and it’s brutal. You’re figuring out which accounts are the same person and then merging them without dropping history, breaking foreign keys, or handing one customer another’s permissions. Email isn’t a stable key, since people have several, share them, and change them. Merging two accounts means reconciling two profile schemas and two sets of entitlements and deciding which one wins. And the whole thing has to be idempotent and auditable, because you will run it more than once and you will have to explain it to a compliance reviewer afterward.
Teams lose months in here. If identity had been centralized from the start, with one provider handing out one stable identifier that every app already trusted, this whole project collapses into routing and UI. That’s the strongest reason to centralize before you think you need to. The payoff isn’t today, it’s the migration you don’t see coming yet.
SSO Is an Architecture Decision Wearing a Convenience Costume
SSO gets sold to users as “fewer passwords to remember.” Fine, but that’s not the interesting part. The interesting part is what it does to your identity architecture: it pulls authentication out of every individual app and puts it in one identity provider that everything else federates with. Okta, Entra ID, Auth0, Ping, Google, Keycloak if you want to host it yourself.
In practice that means standardizing on a handful of well-specified protocols instead of reinventing auth in every service. Worth knowing what each one is actually for, because they get muddled constantly:
OIDC is the identity layer on top of OAuth 2.0. The provider issues a signed ID token, your apps verify the signature against its published keys, and nobody but the provider holds credentials. OAuth 2.0 underneath it is about authorization, what a token is allowed to do, which is a different question from who the user is even though people use the words interchangeably. SAML is the older XML assertion protocol, and you’ll be supporting it for years regardless of how you feel about it, because enterprise and B2B federation runs on it. SCIM is the one everybody forgets, and it’s the one that makes lifecycle real: it standardizes provisioning and deprovisioning so that disabling someone in the provider actually propagates out to the connected apps instead of being a wish.
Once auth lives in one place behind these standards, a bunch of things that were impossible to retrofit app-by-app become policy you set once. Real MFA, including passkeys and other phishing-resistant factors, enforced everywhere instead of wherever someone remembered to add it. Conditional access based on device and network and location. Joiner-mover-leaver flows that provision on hire and actually revoke on departure. Audit logs that share one identifier across every system so the auditor question stops being a research project. And that one stable identifier is what saves you from the consolidation mess above.
The Part the Vendors Skip
Here’s where most writing on this goes soft, so I won’t.
What you’re buying when you buy an IdP is years of specialist work in areas that are each their own product category. Credential hygiene. MFA and WebAuthn. Getting OAuth and OIDC and SAML actually correct. Session and token lifecycle. Account recovery, which is where a shocking number of breaches actually start. Bot and fraud detection. Device trust. The SOC 2 and FedRAMP posture sitting under all of it. Every one of these is a place to be subtly, expensively wrong, and “wrong” here means a breach, not a Jira ticket.
But buying is not free and pretending otherwise insults the reader.
“Don’t build auth” does not mean “no auth work.” You’ll still wire up the OIDC and SAML flows, handle token validation, deal with the one legacy app that only understands a header, and babysit the SCIM mappings. Lock-in is real too: your identifiers, group mappings, and integrations all end up vendor-shaped, and moving providers later genuinely hurts. There’s the SSO tax, the well-worn habit of gating SAML and SCIM behind the priciest enterprise tier, so budget for the clean federated setup costing more than the marketing page implies. And centralizing makes your IdP the highest-value target you own and a single point of failure for everything, so an outage or compromise there is a far worse day than any one app going down. Plan for availability, break-glass access, and blast radius accordingly.
It’s also not all-or-nothing. A managed auth SDK is a perfectly sane middle ground for a product team that needs solid login and isn’t ready to stand up a full enterprise IdP. Self-hosting Keycloak trades the vendor bill for operational ownership, which is a real tradeoff and not automatically the cheaper one. Where you land depends on your scale, your compliance load, and whether identity is part of what you sell or just tax you pay to run the business.
The honest default: unless identity is your product, the hours you’d burn getting to production-grade audited standards-compliant auth and keeping it there are almost always better spent on the thing that actually makes you money. A mature platform gets you there faster and safer than building it again from scratch. That’s a strong default. It’s not a law, and the exceptions are exactly the tradeoffs above.
Identity Is Infrastructure
Nobody argues about spending on databases, networking, or observability. Identity belongs in the same bucket and usually doesn’t get there, which is strange, because everything else sits on top of it. Authentication and authorization, your compliance evidence, the user experience, access governance, and every future migration all assume identity underneath them works.
Treat it as infrastructure and you get a stable user identifier, one place to enforce policy, and an audit trail that holds together. Treat it as an afterthought and the debt doesn’t disappear, it just waits. It comes back during an incident, an audit, an acquisition, or a migration, which are precisely the moments you have the least slack to deal with it.
Bottom Line
Which brings it back to the question from the start: who is this person, and what can they do right now? Fragmented setups answer it worst, and every month identity management stays hard, the debt compounds and the untangling gets more expensive.
Centralizing identity behind a real provider and standard protocols is a security decision, but it’s an architectural and financial one too, with consequences that outlast whoever made the call. Just go in clear-eyed about the integration work, the lock-in, and the risk you’re concentrating. Making that trade on purpose, instead of backing into it, is most of what treating identity like infrastructure actually means.
