Table of Contents
It was near the end of the day on a Friday when our infrastructure team pinged me about yet another SSO integration. A customer needed their OIDC configuration applied manually—specifically, we would need to rebuild the claim mappings and add custom claims for their authorization policy from scratch. Not something I relished this close to the weekend.
At BalkanID, we’re building an AI-driven identity security and access governance platform with three main offerings: Identity and Access Governance (IGA), Copilot, and an Identity Security Posture Management solution that is primarily an Identity Risk & RBAC Analyzer. Yet despite all this innovation, my team and I found ourselves manually wrestling with identity edge cases. Day after day, authentication maintenance was pulling focus—not just from engineering resources, but also from the strategic priorities that really matter for our product and BalkanID’s mission.
That was the moment I knew we needed to swap Ory Kratos for an external customer authentication provider.
The reality of open-source auth with Ory Kratos
Initially, Kratos delivered on the potential we saw in it. We had a headless authentication system we could customize however we wanted. The Go codebase was clean, the identity schemas were flexible, and we felt like we were holding the reins. It was a solid piece of engineering.
But we didn’t anticipate maintaining an authentication system like it’s a second job.
The version trap: The real issue wasn’t any single failing of Kratos but the compound effect of trying to build enterprise-grade authentication while also building our actual product. Every upgrade involved breaking changes that could render our existing customizations inoperable. So, we stayed on an older version, watching the gap between our version and the latest widen.
The multi-tenancy tax: Kratos doesn’t natively support the level of multi-tenancy we needed for enterprise B2B SaaS, so we built it ourselves. But this grew increasingly time-consuming and complex. Every new customer that onboarded meant more custom code to write, more edge cases to resolve, and more vulnerable things that could break.
The support vacuum: When our custom Kratos solution didn’t work as intended, we were on our own. The community Slack is great for basic questions, but debugging production issues with your DIY tenant isolation? That’s all you.
The turning point came when we started looking at the real costs: hours per week spent on auth maintenance, expensive hosting that still required heavy ops involvement, and features we weren’t shipping yet because of auth obstacles.
Searching for alternatives to open source
We gave ourselves a month. That was it. Just one month to find, evaluate, and migrate to a new authentication solution. Any longer and we’d lose the momentum we worked so hard to build.
Our non-negotiables were quickly decided:
Enterprise-grade multi-tenancy for us wasn’t just a nice-to-have—we were already operating with true tenant isolation, per-tenant configurations, multiple environments (dev, staging, and multiple production instances), and tenant-scoped everything. Whatever solution we chose had to match or exceed that standard.
Bring Your Own SSO, which meant setting up single sign-on without the engineering tax we’d grown weary of. Our customers use Okta, Ping, OneLogin, Azure AD/Entra ID, and a dozen other IdPs. We wanted them to be able to connect those themselves, without our team being directly involved. To boot, we needed multiple SSO connections per tenant because we’re serving complex enterprise use cases.
A platform our product team could actually use. If adding a new auth flow meant pulling an engineer off core feature development, we’d missed the mark. We needed a solution that gave us back engineering time, not more code to build from scratch and maintain.
We evaluated the usual suspects, including Auth0, WorkOS (with AuthKit), Clerk, and Descope. All of them had excellent, native multi-tenancy that met our needs.
Here’s how they stacked up:
For us, the difference between Descope and the rest was stark. WorkOS had solid enterprise features, but required engineering resources for any flow changes. Clerk’s SSO wasn’t mature enough for our needs. And while Auth0 checked most boxes, they came with a longer migration timeline and decidedly startup-unfriendly pricing.
Why we chose Descope
What really sealed the deal with Descope wasn’t a single feature or capability that we stacked side-by-side with a competitor. It was how quickly we could validate that Descope could actually solve our challenges.
Within 48 hours, we stood up a working prototype. Our actual authentication flows with Descope’s multi-tenancy, SSO, MFA, and everything. The visual flow builder meant I could drag and drop our entire auth logic (including crucial step-up authentication for sensitive actions) without writing a single line of code. On the UI side, it was just as seamless—we simply embedded the flow, and it felt like a true lift-and-shift from our old system, but without the overhead.
The migration path from Kratos was clean and clear. Three weeks later, we were fully migrated. Not mostly working with some rough edges—totally and completely done. Including customer migration. We saw a technical uplift almost immediately:
Plug-and-play connectors for fraud prevention (Have I Been Pwned for breached password detection, Traceable for anomaly detection, and more at our fingertips)
Identity linking that actually handles our edge cases without extra dev work (including those pesky boomerang employees)
Unlimited environments so we could properly separate dev, staging, and different production instances
FGA support for enabling our dynamic access lifecycle, RBAC analysis, and core identity access governance use cases
Flexible flows that our product team could modify without engineering help
SSO self-service customers could configure all on their own
But perhaps most importantly, we got our Friday nights back. And without giving up control over our customer authentication.
Quick takeaways for fellow devs and startups
After going through this migration, here’s what I wish someone had told me earlier.
When open-source auth makes sense may not always be clear early on. As a relatively young company with lean resources, you might think that DIY is the way to go: it’s (ostensibly) cheaper, affords you a lot of control, and can meet a wide range of use cases. But from a practical standpoint, it can be paralyzing as you scale.
When to go with an external solution is typically the moment you’re serving enterprise customers who expect a litany of advanced features built-in (tenant isolation, robust SSO options, etc.), and you’re scrambling to find enough engineers to deliver them on time. If you’re spending more time maintaining authentication than refining your actual product, you’ve already waited too long.
Red flags that show you’re getting close to the point of no return are things like:
Being stuck on an old version of a solution because upgrading is too painful or complex
When every new auth feature request calls for weeks of custom development
Your team is being pulled in different directions, manually resolving customer issues
You’re building features that existing auth platforms provide OOTB
The idea of upgrading your authentication causes genuine dread (and makes you question all your life choices and consider joining a circus instead)
In your search for a startup-friendly CIAM provider, you’ll hit a lot of marketing buzzwords and opaque pricing pages. I strongly recommend you do your research (like a free or trial plan) before meeting with any of these organizations face-to-face. When you do, ask questions like these:
“Can you show me how SSO configuration / (insert your auth challenge) works, and how much does my team need to be involved?” If they begin by talking about what your engineering team will need to do for your customer onboarding, think carefully about whether it’s worth your time.
“How do I modify auth flows that are already in production? Do I need to change any backend code?” Remember how I wanted to escape the fragility of Ory Kratos? This one was top of mind for us. If there are dealbreakers in terms of coding and on-the-fly flexibility, be sure to ask the tough questions.
“Can you handle multiple login identifiers per user / (insert your user management challenge)?” Don’t be afraid to hold up your concerns, especially if they’re coming directly from enterprise customer requests. If a CIAM provider can’t address the enterprise-grade features your customers expect, it’s time to move on.
Ultimately, the specific questions you’ll ask boil down to your unique use case. If SSO is an essential part of your business, get the full scoop from a potential vendor; if their solution isn’t mature enough, you need to find out. In either case, carefully weigh your hands-on experience with a product (and its support) before taking things further with any prospective provider.
Open source, changing course, and a growth-filled future
My number-one takeaway from all of this? Thousands of lines of code don’t equal control. More to the point, control over your code isn’t the same as control over your outcomes.
If I could do it all over again, I might have migrated sooner. Probably the moment we started serving large enterprises with SSO requirements. The lessons learned are still valuable, though, and I’m grateful we can now return focus to advancing our platform capabilities or expanding our privileged access management (PAM) features.
Here’s my final take: Authentication is a solved problem in most scenarios. Unless you’re in the business of solving it better (good luck), focus on what makes your product unique and attractive to prospective customers. For us at BalkanID, that’s helping organizations implement intelligent identity security and access governance. Not, thankfully, reinventing authentication from scratch.
We’re now exploring Descope’s fine-grained authorization (FGA) for even more sophisticated access control models, and we’re implementing step-up authentication within JITPBAC (Just-In-Time Purpose Based Access Control), our next-gen PAM offering. Could I have built those features within Ory Kratos? Absolutely, eventually. But today, with software so commoditized, it doesn’t make sense to reinvent the wheel, especially when speed to market is critical. The difference now is that these enhancements can be up in days rather than months.
That kind of velocity isn’t just about efficiency — it’s what enables lean teams to innovate, adapt, and scale without losing momentum.
