This is part two in a three-part series. Read the first part here.
Why you don’t want multi-tenant SaaS for your auth
Multi-tenant SaaS requires teams to give away significant ownership and control. It also requires a high degree of trust concerning security. These solutions hijack your authentication to fit their inherent limitations. The better answer is to find a solution that you can tailor to fit your specific needs.
At its core, multi-tenant SaaS is designed to cater to the broadest possible audience, prioritizing the most common use cases over specialized needs. While this approach worked well in 2015, the landscape of Customer Identity has evolved significantly. Organizations today require greater flexibility, control, and configurability—needs that the multi-tenant SaaS model struggles to accommodate.
The risks of renting auth from multi-tenant SaaS
Multi-tenant SaaS introduces significant risks due to shared infrastructure. Here are a few examples of where things can go wrong:
Noisy neighbors & the risk of lateral movement
Multi-tenant SaaS comes with significant security risks, primarily because your uptime and security depend on your “neighbors.” If another tenant experiences an issue—whether it’s a breach, misconfiguration, or service failure—you could face downtime or exposure as well. There have been multiple high-profile breaches demonstrating this vulnerability. Auth0 published an apology blog detailing their efforts to improve platform resiliency due to a consistent set of issues with a multi-tenant architecture.
Privacy and Security
A shared environment also expands the overall attack surface; with more tenants comes more potential entry points for attackers to exploit. Lastly, data residency requirements have become mainstream, driven by strict privacy laws, yet multi-tenant SaaS often makes it nearly impossible to dictate where your data is stored and processed (i.e. you can’t ensure your data is always within the EU). These compromises put your compliance and sovereignty at risk.
Owning your data
Additionally, multi-tenant architectures make it difficult to truly own your data. Extracting it can be complex, as it’s entangled within a shared infrastructure that limits control.
Versioning, anyone? The loss of configuration control
Multi-tenant SaaS often forces development teams to compromise and accept limitations. This is especially true regarding customization, flexibility, and control.
Lack of Versioning & Forced Updates
Multi-tenant SaaS providers apply updates universally, meaning every tenant receives changes at the same time—whether they are ready or not. In some cases, providers might use a continuous deployment model, which means they are upgrading their systems multiple times per day. This lack of versioning removes control over the upgrade cadence, forcing organizations to adapt to potentially breaking changes, unexpected UI shifts, or deprecated functionality without adequate preparation. Businesses operating in regulated industries or with complex dependencies often need more control over when and how updates are applied, something multi-tenant SaaS cannot provide.
Limited API Flexibility
To maintain broad compatibility, multi-tenant SaaS platforms design their integration endpoints around the lowest common denominator. This results in rigid APIs that may lack the depth and flexibility needed for sophisticated integrations. Organizations that require custom claims, advanced token handling, or seamless embedding into existing workflows often find themselves constrained by predefined API structures that cannot be easily extended or modified.
Inability to Deploy Locally and Control Infrastructure
For organizations with strict data residency, compliance, or performance requirements, the inability to deploy locally is a major drawback of multi-tenant SaaS. Because these solutions run on shared infrastructure, customers have little to no control over where their data is stored, how traffic is routed, or what security measures are in place at the infrastructure level. Even in cases where a provider offers region-based hosting, the lack of true infrastructure control can lead to performance bottlenecks, regulatory challenges, and increased risk exposure. For businesses operating in highly regulated industries, a self-hosted or single-tenant solution is often the only viable option.
Multi-tenant SaaS is a total pain in app development
Modern development workflows demand flexibility, speed, and reliability—yet SaaS-only authentication solutions introduce unnecessary friction that slows down teams and increases risk. From the complexities of mocking authentication in testing environments to the productivity drain caused by context switching, developers need more control over their tools. Here’s why relying solely on a multi-tenant SaaS authentication service can be a major obstacle to efficient development and delivery.
The Need to Mock Authentication
When writing automated tests for an application, developers need to simulate real-world interactions as closely as possible. However, if authentication is only available as a cloud-hosted SaaS service, testing becomes significantly more complicated. To work around this, teams often create ‘mocks’—stand-in versions of the authentication service that attempt to replicate its behavior in a controlled environment.
The problem? If a mock isn’t built to perfectly match the real service (which is almost always the case because engineering teams don’t want to write a full authentication platform just to start writing their own automated tests), tests can give a false sense of security. Everything may appear functional when running integration and functional tests, but once deployed to production, authentication could break in unexpected ways. This risk is particularly high for login systems, where even a small mismatch in token handling, session expiration, or authentication flow logic could prevent users from accessing the app entirely.
Developer Productivity
A smooth development workflow requires minimizing distractions and keeping everything readily available. Developers already follow this principle with databases—having a local instance ensures that they can build, test, and iterate without external dependencies. Whether working from an airplane, a park, or a coffee shop, developers expect to be able to run their applications in a fully self-contained environment.
Authentication should be no different. If an auth service is only accessible via the cloud, developers are forced to maintain an internet connection just to test authentication logic. This introduces unnecessary delays, especially when dealing with slow or unreliable networks. More importantly, it slows down productivity — developers must pause their workflow, shift mental focus to external debugging, and wait for a response from a remote service before resuming their work. Every context switch adds friction, reduces momentum, and ultimately slows down development.
This is why many teams are working to bring previously cloud-only services back into local development environments. For example, developers have been demanding ways to develop with AWS Lambdas locally. Authentication services should follow the same approach—by offering a local, self-hosted option, developers can keep their workflows efficient, reliable, and fully within their control.
Scale? Try login lock-out
Multi-tenant architectures are responsible for well-known, public debacles with product launches that failed to scale with exponential increases in traffic.
For example, at launch in July 2016, Pokémon GO faced widespread login failures due to severe server overload, as demand surged to 50 times Niantic’s expectations. The game’s authentication system, particularly for Pokémon Trainer Club accounts, struggled to handle the traffic, while Google-based logins were more stable. Niantic relied on Google Cloud Platform (GCP), but despite its auto-scaling capabilities, the multi-tenant infrastructure couldn’t expand instantly to meet the massive influx of players. Additionally, DDoS attacks further strained the servers, compounding login issues. Niantic acknowledged the problems, attributing them to unexpected demand and infrastructure scaling challenges.
In the last part of this series, we will explain how you can prevent your auth from getting hijacked by multi-tenant SaaS.
