The Scourge of the SSO Tax: Open Source Projects Shouldn't Lock Security Behind Paywalls

What Is the "SSO Tax"?

At the intersection of open source and commercial software, an increasingly controversial phenomenon is sparking growing debate—the "SSO Tax." The SSO Tax refers to the practice of software vendors locking Single Sign-On (SSO), OIDC, SAML, and other identity authentication features behind expensive "Enterprise" or "Professional" tier plans, forcing users who need these capabilities to pay premium prices.

To understand the essence of the SSO Tax, you first need to understand the technical protocols behind it. Single Sign-On (SSO) is an authentication mechanism that allows users to access multiple independent application systems with a single set of credentials. There are two core protocols behind it: SAML (Security Assertion Markup Language) is an XML-based open standard primarily used in enterprise scenarios, enabling SSO by exchanging authentication assertions between Identity Providers (IdP) and Service Providers (SP); OIDC (OpenID Connect) is an identity layer protocol built on top of OAuth 2.0 that uses JSON Web Tokens (JWT) to convey user identity information, and has been widely adopted due to its lightweight nature and friendliness to modern web applications. The shared philosophy of these two protocols is: applications themselves don't need to store and manage user passwords—instead, they delegate the authentication process to specialized identity providers, thereby reducing the security risks that come with each application implementing its own authentication logic.

The SSO Tax phenomenon is extremely prevalent in the SaaS industry. Developers have even created the sso.tax website to document SSO pricing strategies across major software products, and the data shows that many products see price increases of 2-4x when adding SSO support. For example, some project management tools charge $8 per user per month for the standard tier, but jump straight to $25+ per user per month for the enterprise tier with SAML SSO. The vendors' logic is: organizations that need SSO are typically large enterprises with budgets and compliance requirements, so they can absorb higher pricing. But critics point out that this practice essentially weaponizes security features as a price discrimination tool—the implementation cost of SSO is far lower than the premium it commands, and the real purpose is to filter out enterprise customers with higher willingness to pay. In the open source world, this contradiction is even sharper, because community contributors may have directly participated in developing the paid features.

Recently, a veteran open source contributor posted on Reddit, directly calling out the open source email project bichon as yet another victim of the "SSO Tax." The trigger was this: an external contributor proactively submitted a PR (Pull Request) implementing OIDC login, only to discover during the process that this feature would be reserved for a future "Pro version"—meaning community-contributed code could potentially be used as leverage for commercial monetization.

This incident resonated widely because it touches on an increasingly common and sensitive contradiction in the open source ecosystem: How should the boundary be drawn between maintainers' legitimate commercial interests and users' fundamental security rights?

Maintainers Wanting to Earn Money Is Perfectly Reasonable

First, we must acknowledge one thing: it is entirely fair and reasonable for open source project maintainers to want compensation for their labor. The original poster, as a "long-time open source contributor," explicitly stated their understanding of this need.

Open source software has long faced a sustainability crisis. Countless pieces of critical infrastructure are maintained by a handful of volunteers in their spare time, and cases of projects stalling, maintainers burning out, or outright project abandonment due to lack of funding are all too common. This problem has grown increasingly severe in recent years—the 2014 Heartbleed vulnerability revealed that OpenSSL, a core internet encryption library, had long been maintained by only a few part-time volunteers; the 2021 Log4Shell vulnerability exposed similar issues—a logging library depended on by millions of Java applications whose core maintainers received virtually no financial compensation. Nadia Eghbal systematically analyzed this phenomenon in her book Working in Public: there is a massive asymmetry between users and contributors of open source projects, with vast amounts of "digital infrastructure" in a state of under-maintenance. Against this backdrop, mechanisms like Open Source Pledge, Tidelift, and GitHub Sponsors have emerged, attempting to establish sustainable income sources for maintainers.

Therefore, exploring commercialization paths is not the problem itself. The real problem lies in the method of monetization. The original poster sharply pointed out that using SSO/OIDC authentication features as a paid gate is "the worst possible approach." The reason isn't charging per se, but rather what's being charged for—security.

Why SSO Is Fundamentally a Security Feature

The most valuable insight in the post is its redefinition of SSO's nature: It is not a nice-to-have "enterprise convenience feature"—it is core security infrastructure.

The poster's reasoning is crystal clear:

"Your project's homebrew login flow is almost certainly nowhere near as robust as dedicated identity authentication software like Kanidm, PocketID, or Zitadel. Implementing Passkeys, 2FA (two-factor authentication)... these are not trivial tasks."

The key point here is that for the vast majority of applications, identity authentication is not their core value proposition. An email client's value lies in sending, receiving, and managing email. A note-taking app's value lies in knowledge management. Expecting every project to implement a secure, comprehensive login system from scratch—complete with Passkey and multi-factor authentication support—is neither realistic nor wise.

It's worth explaining Passkey, a key technology here. Passkey is a next-generation passwordless authentication technology based on the FIDO2/WebAuthn standard. Unlike traditional passwords, Passkeys use public-key cryptography: a key pair is generated on the user's device, with the private key securely stored locally on the device (such as in a secure chip or password manager) and the public key registered with the server. During authentication, the server issues a challenge, and the user unlocks the private key via biometrics (fingerprint, facial recognition) or a device PIN to sign it—no interceptable password is ever transmitted. This fundamentally eliminates threats like phishing attacks, credential stuffing, and password leaks. Apple, Google, and Microsoft have all fully supported Passkey synchronization across their ecosystems, making it a true replacement for passwords. However, correctly implementing the WebAuthn protocol is no easy task, involving complex registration/authentication flows and compatibility handling for multiple authenticator types.

Delegating to Specialized Identity Providers = Delegating Security

Precisely for this reason, delegating authentication to specialized identity providers (such as Zitadel, Authentik, Keycloak, etc.) via standard protocols like OIDC is effectively handing security responsibility to more specialized teams.

The identity providers mentioned each have their own strengths: Keycloak, developed by Red Hat, is currently the most mature open source IAM (Identity and Access Management) platform, supporting OIDC, SAML, LDAP, and other protocols; Zitadel is a cloud-native identity management system written in Go, emphasizing developer experience and multi-tenancy support; Authentik is an open source IdP known for its flexibility, allowing customization of authentication logic through a visual flow editor; Kanidm is a modern identity management system written in Rust, focusing on security and performance. The significance of these systems is this: identity authentication is an extremely complex domain involving password hashing, session management, token refresh, brute-force protection, account lockout policies, and numerous other security details—centralized maintenance by specialized teams is far superior to each application implementing its own.

By delegating to these specialized systems, users gain:

• Unified multi-factor authentication (2FA)
• Modern passwordless authentication like Passkey/WebAuthn
• Centralized account management and auditing
• Reduced risk of password reuse

In other words, the essence of SSO is enabling ordinary users to enjoy enterprise-grade security protection. When a project locks SSO behind a paywall, it is effectively putting a price tag on "security."

"Pay for Security" Is a Betrayal of Users

The poster used a rather charged statement to express their position:

"If you think not everyone deserves security, then I'm sorry, you don't deserve your users."

While emotionally charged, the logic behind this statement is worth serious consideration. Security should not be a "value-added service" or "premium privilege." When homebrew login systems already carry numerous risks, making the only reliable secure login method (SSO) a paid feature is essentially telling free users: "Your account security isn't worth protecting."

This approach is morally indefensible and practically risky. Free users are forced to use a potentially less robust homebrew authentication system, and when a data breach or account takeover occurs, the damage extends beyond the user to the project's own reputation. From the history of information security, the root cause of the vast majority of major data breaches can be traced back to weaknesses in the authentication layer—weak passwords, lack of multi-factor authentication, improper session token management, etc. When a project knowingly has a more secure solution (SSO integration) but makes it a paid gate, it is artificially creating a security class divide.

A Better Path to Monetization: Sincerely Seeking Donations

So how should maintainers achieve commercialization without sacrificing user security? The poster offers a simple but effective suggestion:

"Seek donations. Set the default donation amount high. If people truly like your software, they will likely donate. But don't put security features behind a paywall."

This suggestion points toward a healthier direction for open source commercialization. Beyond donations, there are actually many sustainable monetization models that don't require sacrificing security:

Viable Alternatives

• Managed Services (SaaS): Offer an out-of-the-box cloud-hosted version, letting users who don't want to self-host pay for peace of mind. GitLab, Sentry, and others have adopted similar models. This "Open Core + Managed Service" strategy has been proven to be one of the most successful paths for open source commercialization—users pay for operational convenience and reliability guarantees, not for the code itself.
• Advanced Collaboration/Management Features: Use genuinely non-security enterprise features like "team collaboration," "advanced analytics," and "approval workflows" as paid differentiators.
• Priority Support and SLAs: Provide technical support guarantees and service level agreements for paying customers.
• Sponsorship and Donations: Platforms like GitHub Sponsors and Open Collective have already made ongoing sponsorship more viable. Open Collective provides a financially transparent sponsorship management framework that lets sponsors clearly see where funds are going; GitHub Sponsors leverages the platform's massive developer base to reduce friction costs of sponsoring.

What these approaches have in common is: they monetize "convenience," "service," and "scale"—not "security" as a fundamental right.

Conclusion: Security Is the Baseline, Not a Selling Point

The bichon project controversy is just one microcosm among many "SSO Tax" cases. As more and more open source projects seek commercialization, how to strike a balance between maintainer interests and user rights will be an ongoing challenge for the entire ecosystem.

This discussion leaves all project maintainers with a clear warning: You can charge for convenience, you can charge for scale, you can charge for service—but please don't charge for security. Because once you push security features behind a paywall, what you're selling out isn't just your product's trust, but the fundamental interests of the community users who have been quietly supporting you.

For the open source community, the ideal state is perhaps this: let security be the default baseline that everyone enjoys, and let commercial value grow naturally along other dimensions.