The Curse 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, a 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 "Pro" tier plans, forcing users who need these capabilities to pay a hefty premium.

To understand the essence of the SSO Tax, you first need to grasp the technical protocols behind it. Single Sign-On (SSO) is an authentication mechanism that allows users to access multiple independent applications 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, achieving SSO by exchanging authentication assertions between Identity Providers (IdP) and Service Providers (SP); OIDC (OpenID Connect) is an identity layer built on top of OAuth 2.0 that uses JSON Web Tokens (JWT) to convey user identity information, and has been widely adopted for its lightweight nature and friendliness to modern web applications. The shared philosophy of both protocols is that 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 inherent in 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 the SSO pricing strategies of major software products, with data showing that many products see price jumps of 2-4x when SSO support is added. For example, some project management tools charge $8 per user per month for the standard plan, but the enterprise tier with SAML SSO jumps straight to $25+ per user per month. The vendors' logic is: organizations that need SSO are typically large enterprises with budgets and compliance requirements, so they can absorb higher pricing. Critics counter that this practice essentially weaponizes security features as a tool for price discrimination — 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 becomes even sharper, as community contributors may have directly participated in developing the paywalled features.

Recently, a veteran open source contributor posted on Reddit, 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 learn during the process that this feature would be designated for a future "Pro version" — meaning community-contributed code could be used as leverage for commercial monetization.

This incident resonated widely because it touches on an increasingly common and sensitive tension in the open source ecosystem: how to draw the line between maintainers' legitimate commercial interests and users' fundamental right to security.

Maintainers Wanting to Earn Money Is Perfectly Reasonable

First, let's acknowledge one thing: it's entirely fair and reasonable for open source project maintainers to seek compensation for their labor. The original poster, as a "long-time open source contributor," explicitly stated they understand 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 abandoning projects due to lack of funding are all too common. This problem has become increasingly severe in recent years — the 2014 Heartbleed vulnerability revealed that OpenSSL, a core internet cryptographic library, had long been maintained by only a few part-time volunteers; the 2021 Log4Shell vulnerability exposed a similar issue — a logging library depended upon 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 open source project users and contributors, with vast amounts of "digital infrastructure" in a state of undermaintenance. Against this backdrop, mechanisms like Open Source Pledge, Tidelift, and GitHub Sponsors have emerged, attempting to establish sustainable income streams for maintainers.

Therefore, exploring paths to commercialization is not the problem in itself. The real issue lies in how monetization is achieved. The original poster pointedly argued that using SSO/OIDC authentication features as a paywall threshold is "the worst possible approach." The reason isn't the charging itself, but what's being charged for — security.

Why SSO Is Fundamentally a Security Feature

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

The poster's argument is crystal clear:

"Your project's homegrown login flow is almost certainly never going to be as robust as dedicated identity authentication software like Kanidm, PocketID, or Zitadel. Implementing Passkeys, 2FA (two-factor authentication)… these are not trivial matters."

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 emails; 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 critical 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, the private key is securely stored locally on the device (such as in a secure chip or password manager), and the public key is registered with the server. During authentication, the server issues a challenge, and the user unlocks the private key via biometrics (fingerprint, facial recognition) or device PIN to produce a signature — no interceptable password is ever transmitted. This fundamentally eliminates threats like phishing attacks, credential stuffing, and password breaches. Apple, Google, and Microsoft have fully supported Passkey synchronization across their respective 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 Professional Identity Providers = Delegating Security

This is precisely why delegating authentication to professional identity providers (such as Zitadel, Authentik, Keycloak, etc.) via standard protocols like OIDC effectively means entrusting security responsibilities to more specialized teams.

The identity providers mentioned in the post 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 raison d'être of these systems is that identity authentication is an extraordinarily 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 professional systems, users gain:

• Unified multi-factor authentication (2FA)
• Modern passwordless authentication via 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's effectively putting a price tag on "security."

"Pay-to-Be-Secure" Is a Betrayal of Users

The original poster used a rather strong statement to express their position:

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

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

This approach is morally indefensible and practically dangerous. Free users are forced to use a potentially less robust homegrown authentication system, and when a data breach or account compromise occurs, the damage extends beyond just the users — it hits the project's reputation as well. Looking at the history of information security, the root causes 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, and so on. When a project knowingly has a more secure solution available (SSO integration) yet designates it as a paid feature, it is artificially creating a tiered security hierarchy.

A Better Way to Monetize: Sincerely Seeking Donations

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

"Seek donations. Set the default donation amount higher. If people truly like your software, they will very 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 — none of which require sacrificing security:

Viable Alternatives

• Managed Services (SaaS): Offer a ready-to-use cloud-hosted version, letting users who don't want to self-host pay for convenience. GitLab, Sentry, and others have adopted similar models. This "Open Core + Managed Service" strategy has been proven as one of the most successful paths to open source commercialization — users pay for operational convenience and reliability guarantees, not for the code itself.
• Advanced Collaboration/Management Features: Designate genuinely non-security enterprise features like "team collaboration," "advanced analytics," and "approval workflows" as paid tiers.
• 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 made sustained sponsorship increasingly viable. Open Collective provides a financially transparent sponsorship management framework, letting sponsors clearly see where funds go; GitHub Sponsors leverages the platform's massive developer base to reduce friction in sponsoring.

What all these approaches have in common is that 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 example 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 product trust — it's the fundamental interests of the community users who have been quietly supporting you all along.

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