Language updates

astro/src/content/blog/multi-tenant-hijack-2.mdx

@@ -11,69 +11,75 @@ excerpt_separator: "{/* more */}"
 
 This is part two in a three-part series. Read the first part [here](/blog/multi-tenant-hijack).
 
-## Why you don’t want multi-tenant SaaS for your auth
+## Why You Don't Want Multi-Tenant SaaS for Your Auth
 {/* more */} 
 
 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.
 
+Let’s cover each of the four major pain-points and concerns that arise when using a multi-tenant SaaS solution: Risks, Control, Developer headaches, and Scale.
+
 ![The struggles of a multi-tenant SaaS model](/img/blogs/multi-tenant-saas/saas-struggles.png)
 
-## The risks of renting auth from multi-tenant SaaS
+## 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
+### 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](https://auth0.com/blog/improving-our-platform-resiliency-and-upcoming-holiday-plans/) 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.
+A shared environment also expands the overall attack surface; with more tenants comes more potential entry points for attackers to exploit. Additionally, data residency requirements have become mainstream, driven by strict privacy laws. Multi-tenant SaaS solutions often make 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 limitations put your compliance and sovereignty at risk.
 
-### Owning your data
+### 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.
+At its core, 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. Some solutions won’t even provide you access to your data, which should be considered a “show-stopper” for anyone evaluating vendors (cough, cough, Cognito).
 
-### Versioning, anyone? The loss of configuration control
+## How Multi-Tenant SaaS Takes Away Your Control
 
-Multi-tenant SaaS often forces development teams to compromise and accept limitations. This is especially true regarding customization, flexibility, and control.
+Multi-tennant SaaS often forces development teams to compromise and accept limitations. This is especially true when considering versioning, 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.
+Multi-tenant SaaS providers apply updates universally, meaning every tenant receives changes at the same time—whether everyone is 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 eliminates  your control over the upgrade cadence, forcing you to adapt to potentially breaking changes, unexpected UI shifts, or deprecated functionality reactively rather than proactively. If you are operating in regulated industries or with complex dependencies, you likely need more control over when and how updates are applied. No multi-tenant SaaS solution can provide this guarantee. This is particularly painful when the provider rolls an update on Saturday night at 2am that breaks your entire application and you have to scramble to roll your own patch as quickly as possible.
 
 ### 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.
+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. If your application requires custom claims, advanced token handling, or seamless embedding into existing workflows, you might find yourself 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.
+Additionally, if your application has 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, you have little to no control over where your 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. If your business operates in a highly regulated industry, a self-hosted or single-tenant solution might be the only viable option.
 
-## Multi-tenant SaaS is a total pain in app development
+## The Pain of Multi-Tenant SaaS for 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.
+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.
+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 complex (or some might say painful). To work around this, development 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.
+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 will give a false sense of correctness. Everything may appear functional when running integration and functional tests, but once your app is deployed to production, authentication and user data integrations 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](https://www.reddit.com/r/aws/comments/ajjd2s/how_can_you_developwrite_lambda_functions_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.
+And let’s not even dive into how slow tests run when they have to make thousands of calls to an external service (do you get cold sweats thinking of running tests against Stripe that take 3-4 hours?). And that external service might throttle your tests if you make too many calls. Or they could cut you off completely, causing full test runs to fail or CI/CD to fail at a critical moment.
+
+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](https://www.reddit.com/r/aws/comments/ajjd2s/how_can_you_developwrite_lambda_functions_locally/). Authentication services should lead this charge! Authentication is a critical infrastructure component, so it should stand to reason that it should always run locally for testing, CI, and CD. Why would you let your deployments fail because your auth provider has throttled or blocked access to your test account?
 
-## Scale? Try login lock-out
+## Scaling Up? Beware of 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](https://www.forbes.com/sites/davidthier/2016/07/07/pokemon-go-servers-seem-to-be-struggling/) 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.
 
+Your application might not instantly need to login 10,000 users per second. Or handle 20,000 registrations per second. But wouldn’t that be a great problem to have? And why wouldn’t you pick a solution that could handle that scale without blinking an eye or require a lengthy contract negotiation before they would move your authentication over to their “Dedicated Cloud”. Wouldn’t you sleep better at night knowing that your login could instantly scale to whatever you needed?
+
 In the last part of this series, we will explain how you can prevent your auth from getting hijacked by multi-tenant SaaS.