SSO税之殇：开源项目不该把安全功能锁进付费墙

什么是"SSO税"？

在开源与商业软件的交界地带，一个颇具争议的现象正引发越来越多的讨论——"SSO税"（SSO Tax）。所谓SSO税，指的是软件厂商将单点登录（Single Sign-On）、OIDC、SAML等身份认证功能锁定在昂贵的"企业版"或"专业版"套餐中，迫使需要这些功能的用户支付高额费用。

要理解SSO税的本质，首先需要了解其背后的技术协议。单点登录（SSO）是一种身份认证机制，允许用户使用一组凭据访问多个独立的应用系统。其背后的核心协议主要有两种：SAML（Security Assertion Markup Language）是一种基于XML的开放标准，主要用于企业级场景，通过在身份提供商（IdP）和服务提供商（SP）之间交换认证断言来实现SSO；OIDC（OpenID Connect）则是建立在OAuth 2.0之上的身份层协议，使用JSON Web Token（JWT）传递用户身份信息，因其轻量级和对现代Web应用的友好性而被广泛采用。这两种协议的共同理念是：应用本身不需要存储和管理用户密码，而是将认证过程委托给专业的身份提供商，从而降低每个应用各自实现认证逻辑所带来的安全风险。

SSO税现象在SaaS行业中极为普遍。有开发者专门创建了sso.tax网站来记录各大软件产品的SSO定价策略，数据显示许多产品在添加SSO支持时价格暴涨2-4倍。例如，某些项目管理工具的标准版每用户每月8美元，但支持SAML SSO的企业版直接跳升至每用户每月25美元以上。厂商的逻辑是：需要SSO的通常是大型企业，它们有预算也有合规需求，因此可以承受更高定价。但批评者指出，这种做法实质上是将安全功能作为价格歧视工具——SSO的实现成本远低于其带来的溢价，真正的目的是筛选出支付意愿更高的企业客户。在开源领域，这一矛盾更加尖锐，因为社区贡献者可能直接参与了付费功能的开发。

近日，一位资深开源贡献者在Reddit上发帖，直指开源邮件项目 bichon 成为了"SSO税"的又一个受害者。事件的导火索是：一位外部贡献者主动提交了一个实现OIDC登录的PR（Pull Request），却在此过程中才得知——这项功能将被划入未来的"Pro版本"，也就是说，社区贡献的代码可能被用作商业变现的筹码。

这一事件之所以引发广泛共鸣，是因为它触及了开源生态中一个越来越普遍、也越来越敏感的矛盾：维护者的合理商业诉求，与用户基本安全权益之间的边界该如何划定。

维护者想赚钱，无可厚非

首先必须承认一点：开源项目的维护者希望从自己的劳动中获得回报，这完全合情合理。发帖者作为一名"长期的开源贡献者"也明确表示理解这种需求。

开源软件长期以来面临着可持续性危机。无数关键基础设施由少数几位志愿者在业余时间维护，缺乏资金支持导致项目停滞、维护者倦怠（burnout）甚至彻底放弃项目的案例屡见不鲜。这一问题在近年来愈发严峻——2014年的Heartbleed漏洞揭示了OpenSSL这一互联网核心加密库长期仅由少数几位兼职志愿者维护的窘境；2021年的Log4Shell漏洞再次暴露了类似问题——一个被数百万Java应用依赖的日志库，其核心维护者几乎没有获得任何经济回报。Nadia Eghbal在其著作《Working in Public》中系统性地分析了这一现象：开源项目的使用者与贡献者之间存在巨大的不对称性，大量"数字基础设施"处于维护不足的状态。这种背景下，Open Source Pledge、Tidelift、GitHub Sponsors等机制应运而生，试图为维护者建立可持续的收入来源。

因此，探索商业化路径本身并不是问题。真正的问题在于变现的方式。发帖者尖锐地指出，把SSO/OIDC这类身份认证功能作为付费门槛，"是最糟糕的一种做法"。原因不在于收费本身，而在于收费的对象——安全。

为什么SSO本质上是安全功能

这篇帖子最有价值的洞察在于，它重新定义了SSO的性质：它不是一项锦上添花的"企业便利功能"，而是一项核心的安全基础设施。

发帖者的论证逻辑非常清晰：

"你的项目自建登录流程，几乎不可能有 Kanidm、PocketID、Zitadel 这类专用身份认证软件那么健壮。实现Passkey、2FA（双因素认证）……这些都不是小事。"

这里的关键在于，对于绝大多数应用来说，身份认证并不是它的核心价值所在。一个邮件客户端的价值在于收发和管理邮件，一个笔记应用的价值在于知识管理。让每个项目都从零实现一套安全、完善、支持Passkey和多因素认证的登录系统，既不现实，也不明智。

这里有必要解释一下Passkey这项关键技术。Passkey是基于FIDO2/WebAuthn标准的新一代无密码认证技术。与传统密码不同，Passkey使用公钥密码学：用户设备上生成一对密钥，私钥安全存储在设备本地（如安全芯片或密码管理器中），公钥注册到服务端。认证时，服务端发起挑战（challenge），用户通过生物识别（指纹、面部识别）或设备PIN解锁私钥进行签名，全程无需传输任何可被截获的密码。这从根本上消除了钓鱼攻击、凭据填充和密码泄露等威胁。Apple、Google、Microsoft已在各自生态中全面支持Passkey同步，使其成为密码的真正替代方案。然而，正确实现WebAuthn协议并非易事，涉及复杂的注册/认证流程和多种认证器类型的兼容处理。

委托专业身份提供商 = 委托安全

正因如此，通过OIDC等标准协议将认证委托给专业的身份提供商（如Zitadel、Authentik、Keycloak等），实际上是把安全责任交给了更专业的团队。

文中提到的这些身份提供商各有特色：Keycloak由Red Hat开发，是目前最成熟的开源IAM（身份认证与访问管理）平台，支持OIDC、SAML、LDAP等多种协议；Zitadel是用Go编写的云原生身份管理系统，强调开发者体验和多租户支持；Authentik是一个以灵活性著称的开源IdP，允许通过可视化流程编辑器自定义认证逻辑；Kanidm则是用Rust编写的现代身份管理系统，注重安全性和性能。这些系统的存在意义在于：身份认证是一个极其复杂的领域，涉及密码哈希、会话管理、令牌刷新、暴力破解防护、账户锁定策略等众多安全细节，由专业团队集中维护远优于每个应用各自实现。

通过委托这些专业系统，用户可以获得：

统一的多因素认证（2FA）
Passkey/WebAuthn等现代无密码认证
集中化的账户管理与审计
更少的密码复用风险

换句话说，SSO的本质是让普通用户也能享受到企业级的安全防护。当一个项目把SSO锁进付费墙时，它实际上是在给"安全"标价。

"付费才安全"是对用户的背叛

发帖者用了一句相当激烈的话来表达立场：

"如果你认为不是每个人都应该拥有安全，那么很抱歉，你不配拥有你的用户。"

这句话虽然情绪化，但背后的逻辑值得深思。安全不应该是一种"增值服务"或"高端特权"。当自建登录系统本身就存在诸多隐患时，将唯一可靠的安全登录方式（SSO）设为付费功能，等于是在告诉免费用户："你们的账户安全不值得保护。"

这种做法在道德上站不住脚，在实践中也埋下隐患。免费用户被迫使用一套可能不够健壮的自建认证系统，一旦发生数据泄露或账户被盗，受损的不仅是用户，也是项目自身的声誉。从信息安全的历史来看，绝大多数重大数据泄露事件的根因都可追溯到认证环节的薄弱——弱密码、缺乏多因素认证、会话令牌管理不当等。当一个项目明知有更安全的方案（SSO集成）却将其设为付费门槛时，它实际上是在人为制造安全等级分化。

更好的变现之道：真诚地寻求捐赠

那么，维护者到底应该如何在不牺牲用户安全的前提下实现商业化？发帖者给出了一个朴素但有效的建议：

"去寻求捐赠。把默认捐赠金额设置得高一些。如果人们真的喜欢你的软件，他们很可能会捐赠。但不要把安全功能设成付费墙。"

这个建议指向了开源商业化的一个更健康的方向。除了捐赠之外，可持续的变现模式其实有很多，而且都不必以牺牲安全为代价：

可行的替代方案

托管服务（SaaS）：提供开箱即用的云端托管版本，让不想自己运维的用户付费省心。GitLab、Sentry等都采用了类似模式。这种"Open Core + Managed Service"的策略已被证明是开源商业化最成功的路径之一——用户为运维便利和可靠性保障付费，而非为代码本身付费。
高级协作/管理功能：将真正的"团队协作"、"高级分析"、"审批工作流"等非安全类企业功能作为付费点。
优先支持与SLA：为付费客户提供技术支持保障、服务等级协议。
赞助与捐赠：GitHub Sponsors、Open Collective等平台已经让持续性赞助变得更加可行。Open Collective提供了财务透明的赞助管理框架，让赞助者清晰看到资金的流向；GitHub Sponsors则利用平台的巨大开发者基数降低了赞助的摩擦成本。

这些方案的共同点在于——它们变现的是"便利"、"服务"和"规模"，而非"安全"这一基本权利。

结语：安全是底线，不是卖点

bichon项目的争议只是众多"SSO税"案例中的一个缩影。随着越来越多的开源项目寻求商业化，如何在维护者利益与用户权益之间取得平衡，将是整个生态需要持续面对的课题。

这场讨论给所有项目维护者留下了一个清晰的警示：你可以对便利收费，可以对规模收费，可以对服务收费，但请不要对安全收费。 因为一旦把安全功能推入付费墙，你出卖的不仅是产品的信任，更是那些默默支持你的社区用户的基本利益。

对于开源社区而言，最理想的状态或许是：让安全成为每个人默认享有的底线，而让商业价值在其他维度上自然生长。