Open Source SaaS is Dead; Long Live Open Source
authentik is an open source Identity Provider that unifies your identity needs into a single platform, replacing Okta, Keycloak, and Ping. Authentik Security is a public benefit company building on top of the open source authentik project.
The Open Source Security Debate
Last week, the CEO of Cal.com announced that the company was going closed source. As he put it, "continuing as open source would put our application, our customers, and the sensitive data we handle at significant risk" due to "AI-driven security threats."
Cal.com is arguing for security through obscurity. But long-term, obfuscation is a losing strategy against a tireless attacker.
Going from open to closed source doesn't mean that the previous information disappears. You can shuffle things around in the dark, and this decision might buy them a little extra time to shore up known vulnerabilities, but they're not going to rearchitect entirely. And what if the proprietary source code is later leaked (say, as has already been the case for both Okta and Auth0's codebases)? Now attackers can feed that hidden map, albeit perhaps a bit outdated, into their tooling, but the rest of the community doesn't get to see how things are (or aren't) secured.
Should we protect our methods of encryption by moving them to closed source? our databases? Should Linux go closed source?
The real difference here is not that calendar booking is any less critical to secure, or even whether the source code is publicly available; the issue is vendor-hosted SaaS. Cal.com's primary business is to sell SaaS subscriptions. That means the company is tasked with directly protecting all of its customers' sensitive data, using its own infrastructure. This is a single, massive target that's worth attacking. If someone can spend enough tokens to find a vulnerability in this publicly accessible infrastructure, this potentially means immediate access to all data accessible by the Cal.com team across tens of thousands of accounts.
We work with multiple federal agencies, Fortune 500's, and other leading providers who handle extremely sensitive data. In terms of high-value targets, authentik is also securing plenty of critical infrastructure and sensitive data. However... while it's the same underlying code everywhere, it's not the same shared, publicly available SaaS. Many of these authentik instances are entirely airgapped. They are all scoped down to "expected" use, whether through specific authentication and user access policies, locking down endpoints that don't need to be publicly accessible, or a customer's own firewall. While finding a critical vulnerability in authentik wouldn't be good, it would also be much less likely to result in an immediate breach of data across all our customers compared to a shared SaaS model.
For a customer, a shared SaaS environment means that you get to rely on the same one-size-fits-none infrastructure as every other customer. The more popular the solution, the bigger the shared attack surface. Closed source SaaS just means that you have even less visibility into how that surface is secured (or not). See the open letter from JPMC's CISO on just how broken this current system is. As he puts it, "The modern SaaS delivery model is quietly enabling cyber attackers and – as its adoption grows – is creating a substantial vulnerability that is weakening the global economic system."
With self-hosted software like authentik, you can run it entirely on your internal network with VPN-only access, you could run a WAF that limits traffic, you could set it up with customizable authentication flows that require multiple forms of authentication, certificates to verify clients, and device compliance measures specific to your organization's use case - all while you have full visibility into everything.
Relying on SaaS solutions like Entra, Okta, or Google Workspace to secure your entire organization, you could be under attack and not even have a way to know it. Vendor-hosted SaaS infrastructure also risks turning your organization into collateral damage from attacks not even targeted at you.
As Vercel demonstrated this past weekend, when it comes to SaaS (or PaaS), the weakness doesn't even have to exist in the closed source code itself - and often doesn't. In this most recent case, a Vercel employee using Context.ai ("Sign in, connect your tools, and configure agents against real workflows") had a Google Workspace token lead to the compromise of private information from multiple customers. As our industry as a whole rapidly adopts more vibecoded AI tools to vibecode our tools, handing over access to sensitive data with no consideration for security, these incidents will only increase in regularity.
On Being a Big Target
Linus's Law that "given enough eyeballs, all bugs are shallow" has now been expanded to include LLMs. Perhaps we need Mythos' Law for modern times: "given enough tokens, all vulnerabilities are shallow."
Many have argued recently that this now reduces security to simple economics: whoever spends more on tokens, "wins." While this is a convenient position for token sellers, and is partially true, it's not the whole story. The attacker-defender dynamic has always been an economic balance. Making a perfectly secure system of any sufficient complexity has always been an unattainable dream. Having good security means taking steps that match your risk profile, to defend against practical threats.
The locks you use on your home are probably a grade below those of a commercial building, which are in turn far below the security systems used by critical data facilities. These choices are practical, economic ones to match their threat models.
While automated tools have over time made it easier for attackers to "spray and pray" against many targets, automated defenses have also improved.
So the actual calculation is no different than before, and must include: how big and how easy of a target are you? And crucially, do you look exactly like everyone else around, or does your security have some level of costly uniqueness to it that an attacker must bypass?
Some have pointed out that "cracking a widely used OSS package is inherently more valuable than hacking a one-off implementation, which incentivizes attackers to spend more on OSS targets." That's again partially true - but it depends on who uses the one-off implementation. If it is a complex, wide-ranging solution used by a federal agency or an extremely large organization, there might be more eyes on it than on a simple OSS tool. If the one-off implementation is a single piece of software that's relied on by a large percentage of large businesses, the calculus changes drastically. And if you are in a shared SaaS environment, the size of the target is not your account or organization individually, but the sum total of all customer data relying on the shared service for security.
Part of the surprise coming out of Mythos' findings was that some of these critical vulnerabilities had been sitting there in the open for anyone to find for years. But now, as more powerful tools get released more broadly, anyone can find such overlooked exploits. While the effort might be higher for closed source code, the reward is also higher. As an attacker, if you have sufficiently mapped out a closed source project well enough, or obtained an inevitable leak of the source code, you now have a unique advantage; it turns the 'strength' of the closed source to an irreparable liability.
Closed source means that it's entirely up to the internal team to identify and patch every vulnerability before attackers find it. This is already plenty tough, but the business incentives are also no longer aligned with closed source, especially for SaaS: it's now in a company's financial interest to provide as little transparency as possible when incidents occur or vulnerabilities are found. (With open source/source available code, while you could argue that a company has similar incentives to downplay issues, there's nowhere to hide; either a vulnerability existed and was patched, or it wasn't.)
We have already begun receiving an increasing number of legitimate AI-enabled security reports from our community; closed source software is not receiving these reports, but it will still be the target of attackers with a similar variety of tools at their disposal.
Having publicly available source code is the faster way to find and close any existing vulnerabilities in your codebase, through transparency and aligned incentives. As Cal.com's own security partner put it, "closing your source code does not stop an AI from probing your API or finding an authorization bypass in your webhooks. It just removes the good eyeballs from your codebase while leaving your attack surface completely visible to the bad ones."
Relying on obfuscation has always been a losing battle that benefits attackers in the long-run. See: a long history of attempts at secret encryption schemes, proprietary file formats, and obscured API endpoints. Betting the value of your IP on the fact that it will never be examined is only a way to buy some time before the inevitable.
When a SaaS company runs closed source, its customers and community are left to hope that the company itself has adequate security in place based on any public assurances. The company is incentivized to invest just enough in security so that no obvious breaches occur - and if they do, to ensure that the cost of those issues is kept to a minimum. Beyond complying with regulations (assuming non-compliance results in a fine or reputation cost large enough to negate that risk), the company is disincentivized to proactively secure beyond this point or to let its customers and community know when vulnerabilities are found or patched.
We have seen this lack of transparency play out in practice many times. For instance, throughout September and October 2023, Cloudflare, BeyondTrust, and 1Password all detected breaches that pointed back to their Okta instances. While you can read details of the breach from each of their blog posts (1, 2, 3), what followed after Okta had been informed by its own customers of a breach was a slow process of partial disclosures.
Even if a closed-source SaaS does try their best to keep things secure and under wraps, there's only so much a single team can do with a big enough target painted on its back. As Cal.com's CEO put it himself, "there's no one platform that seems to be able to reliably find all vulnerabilities, and so simply adopting AI scanners just isn't enough." Closing your source may buy some time by temporarily making some attacks more costly, but it mainly closes off the community and customers who could have helped to continue securing the code they rely on at scale.
When a company is built around open source and source available code, the company's incentive is to keep that code secure and patched; there is no hiding. Customers and community members can run their own tests, and report results back directly to improve the code. They are able to review the code and past mitigations directly. The "eyes of the many" now include the broad-ranging toolsets of the many, and paying customers with aligned incentives can report back findings to further improve the code.
We have over 500 direct contributors and thousands of reviewers, as well as thousands of customers including government agencies, defense contractors, and financial institutions with some of the strictest security requirements imaginable. All of them are continuously scanning and investigating authentik. We receive security reports that not only point out potential flaws but analyze the code that's involved. Closed source, vendor-hosted SaaS solutions are at best limited to occasional "there might be a problem" reports.
Competitive Challenges
There is another growing argument against open source: with the rapidly dropping cost of producing code to match a given set of specifications, won't someone just copy the project?
(For a recent, very meta example, see: the Claude Code rewrite in Rust. Of course, that was a rewrite of leaked, previously proprietary code, once again demonstrating an earlier point...)
This argument is almost identical to hiding your source code away in the hopes that it improves security. It's a long-term losing battle. Yes, it's more costly upfront to copy a project without starting from its source code, but only incrementally so. And the value is higher for a project that is not already open source, since not everyone has access to an existing free version already.
When a project has a good test suite and thorough documentation, this also makes it easier to copy, since how everything should work is written out and publicly available. Does this mean we should instead hide our tests away, or make documentation only available to paying customers, or intentionally incomplete? All that does in the long term is to worsen not just the product and the user experience, but the overall security of the project as well.
Instead, our value is in our team's expertise, our vision for the product, and our community. Yes, with an MIT license, someone could clone our project and start selling Inauthentik™ tomorrow. But with enough Claude Code tokens and a little creativity, they could increasingly do that to any other existing software as well, regardless of license or source code availability. If a team wants to do that for themselves, and then continue to maintain that version as a full-time job for themselves, they are welcome to attempt it. But from a competitive standpoint, an overnight fork does not create product expertise or build community.
Since our licensed enterprise functionality is also source available, it's also much more obvious and provable when someone attempts to copy our licensed code. Without getting into too much detail here, as it's one place I cannot be as transparent as I would like, the fact that all of our code is source available makes legal challenges much more straightforward when they do become necessary.
Changing Times
The security landscape is changing, and we recognize that there are proactive measures all companies and projects should be taking to keep up with the times, regardless of hosting or code source availability.
We already get external, human-driven pentests at least once a year, in addition to the testing that our customers regularly perform on our code and their own authentik implementations. (While the vast majority of authentik's code is open source, even our enterprise functionality is entirely source available, allowing these customers full visibility and transparency.) Although we will probably continue with annual pentests for compliance reasons, this is clearly insufficient by itself. We are spending significant time and dollars on automated tooling to provide ongoing tests for vulnerabilities, and we will be keeping an eye toward emerging offensive and defensive capabilities.
In addition to investing in additional automated testing, and adding AI tooling at various points in our development process to test for potential vulnerabilities, we are also investing in human experts. As we expect the number and speed of inbound security reports to increase, we are actively hiring dedicated security engineers to focus on triaging and validating these reports.
We are also proactively prioritizing additional functionality in authentik to help customers minimize what we see as likely attack vectors where we can play a role in prevention. For instance, with our next release we will be adding an "account lockdown" feature by which users or their admins can instantly deactivate their user account at the moment a compromise is suspected, for instance from a questionable clicked external link. This disables a user's account, sets a user's password to a random value, revokes all tokens, and terminates all open sessions across devices for the user, limiting the blast radius of a potential compromise.
Stay in Touch
A sincere thank you to our community, users, and customers for all collaborating with us to make authentik excellent. While running an open core company comes with many challenges, we remain firm in our commitment to prioritizing security and transparency. Taking visibility away from our community is not a winning strategy.
We look forward to continuing to build authentik in the open and make it the best possible choice of identity provider for millions around the world. If you are ready to take control of your identity and access needs, give authentik a try or get in touch with our team.