CAS已死，别再提了，Keycloak vs MaxKey，你站谁？

你们公司有几套系统？别装了，我知道你密码写在便利贴上

先说个真事。上个月我去一家中型企业做技术咨询，他们有23套内部系统——ERP、CRM、OA、HR、财务、项目管理、知识库、内容审核……每个系统都有自己的账号体系。员工入职要开23个账号，离职的时候要关23个账号。结果呢？上午刚开除了一个员工，下午他还能登录财务系统——因为财务系统的账号根本没人记得要关。这不是个例，这是行业常态。

你可能会说：“我们公司就三五套系统，没那么夸张。”但你想想，每次新员工入职，IT部门要花多少时间开账号？每次密码策略调整，要通知多少人？每次安全审计，要查多少套系统的权限？这些隐性成本加起来，远比你想象的可怕。更别说那些写在便利贴上的密码了——你以为同事们不知道，其实全公司都知道。

这就是为什么单点登录（SSO）不是“锦上添花”，而是“不做就会死人”的事情。但问题来了：市面上的SSO方案那么多，CAS、Keycloak、Auth0、Okta、MaxKey……你究竟该选谁？这篇文章不是什么“全面对比”，而是我亲身踩坑之后的真实感受。你可以不同意，但请先看完再喷。

💬 你们公司有几套系统？密码管理是怎么搞的？评论区说说你见过最离谱的身份管理是什么样的？

先说结论：Keycloak很强，但我不敢用

我知道这句话会惹怒不少人。Keycloak是Red Hat出品的开源IAM，生态完善、文档丰富、社区活跃，全球有数百万开发者在用。我自己也在个人项目里用过Keycloak，体验确实不错。但当我把它放到一个中国企业的生产环境里，事情就变味了。

第一个坑：本地化。Keycloak的界面是英文的，文档是英文的，社区讨论是英文的。你可能觉得这不是问题，但请想象一下：当你的运维同事凌晨两点在Keycloak的官方文档里翻找如何配置微信扫码登录的时候，他会是什么心情。更别说当你需要对接钉钉、企微、飞书这些国内平台的时候，Keycloak的社交登录插件体系基本就是为了Google、Facebook、GitHub设计的，想接钉钉？自己写SPI插件吧。

第二个坑：部署复杂度。Keycloak依赖Java运行时、数据库（默认PostgreSQL或MariaDB）、Infinispan缓存集群……光是把它跑起来就需要一套完整的Java微服务基础设施。对于很多中小企业来说，他们的运维团队可能就两三个人，让他们去维护一套Keycloak集群？不如直接让他们编译内核。而MaxKey同样是Java技术栈，但它的部署流程明显更轻量，单机即可跑起来，集群部署也有明确的文档支持。

第三个坑：商业支持。当你的系统挂了，你需要找人。Keycloak背后是Red Hat，但Red Hat的商业支持是要钱的，而且不便宜。更关键的是，你打电话过去，对方告诉你“请先升级到RH-SSO 7.6”，而你现在跑的是开源版本20.0。这种开源版和商业版的割裂感，在企业级场景下是致命的。而MaxKey虽然也有商业版，但开源社区的响应速度和国内沟通效率明显更高——毕竟大家都在微信群里，说中文就能解决问题。

“Keycloak是一个伟大的项目，但伟大不等于适合你。选技术不是选最强的，是选最匹配的。”

💬 Keycloak vs MaxKey，你站谁？有没有用Keycloak做过国内企业项目的，来说说你的体验？

CAS已死，别再提了

没错，我说的就是Apereo CAS。这个曾经的SSO领域的绝对王者，现在已经基本停滞了。上次CAS的重要版本更新是什么时候？你可能已经想不起来了。GitHub上的提交频率已经说明了一切，社区活跃度早已不复当年。但奇怪的是，我还是经常看到有人在技术选型的时候写“CAS”——大多是因为历史原因，老系统就是用CAS做的，新人接手也就沿用了。

CAS的问题不是它不好，而是它停在了一个历史节点上。它的架构设计是在十年前的思维下完成的：单体应用、服务端渲染、重后端轻前端。而现在的趋势是什么？前后端分离、微服务、API Gateway、多租户。CAS对这些新场景的支持就像是给一辆老桑塔纳装了个测距雷达——能装，但别扭。

更致命的是CAS的文档。如果你试过在CAS上配置OAuth2或者OIDC，你就知道那种感觉——文档写了，但好像又没完全写；示例给了，但好像跑不起来；报错了，去Stack Overflow上找，发现答案是三年前的。这就是CAS现在的状态：不是不能用，而是用起来太累。

💬 你们还有项目在用CAS吗？是因为历史原因还是主动选择？

初见MaxKey：“这就是给中国企业做的”

第一次打开MaxKey的登录页面，我的第一反应是：“这就是给中国企业做的。”不是那种“中国特色”的套路话，而是实实在在的感受——钉钉登录、企业微信登录、飞书登录、手机验证码登录，这些全都是开箱即用的。不需要你写什么SPI插件，不需要你去研究什么协议适配器，点开配置就能用。

MaxKey的全名是“Marx Key”，意思是“万物之钥”。它是dromara开源社区的顶级项目之一，GitHub上超过4000个Star。但说实话，和Keycloak的数万Star相比，这个数字确实不够看。不过，我要说的是：在企业级工具的选择上，Star数从来不是决定性因素。你看你的生产环境用的数据库、消息队列、缓存系统，有几个是GitHub上Star最多的？

MaxKey的核心价值在于它的“开箱即用”程度。它预置了国内企业最常用的身份认证方式：账号密码、手机验证码、钉钉扫码、企业微信、飞书、人脸识别、动态口令、RADIUS……这些在Keycloak上需要自己开发或找第三方插件的东西，在MaxKey里就是勾个选项的事。这种差距在技术评审的时候不明显，但在项目落地的时候会被放大十倍。

协议支持：不是越多越好，而是要刚好需求

先看一组数据。MaxKey支持的身份认证协议包括：OAuth 2.0、OIDC、SAML 2.0、CAS、JWT、Token-Based、Form-Based、AD/LDAP、RADIUS。这个列表看起来很长，但我要说的重点不是“多”，而是“刚好”。

特别说一下RADIUS。这个协议在很多技术人的视野盲区里，但在传统企业和政务领域，它是网络设备认证的标配。V**、无线控制器、交换机这些设备都用RADIUS做认证。Keycloak不支持RADIUS，这意味着你要么再搞一套FreeRADIUS，要么就放弃统一身份认证的想法。而MaxKey原生支持RADIUS，这一个功能就能省掉你好几天的工作量。

当然，我不是说协议支持越多越好。事实上，如果你的场景就是OAuth2 + OIDC，那Keycloak的实现确实更成熟。但问题是，真实的企业场景很少是纯粹的。你总会有那么一两个老系统跟CAS，那么一两个网络设备跟RADIUS，那么一两个政务系统跟SAML。这时候，“全协议支持”就不是锦上添花，而是刚需了。

架构设计：看似简单，实则精妙

MaxKey的架构是经典的星形拓扑：所有应用系统都通过中心的身份网关进行认证，没有应用之间的直接认证关系。这种架构的好处是显而易见的：单点控制、统一策略、集中审计。但很多人忽略了它的另一个优势：当你需要把某个应用从旧的认证体系迁移到MaxKey时，你只需要修改这个应用的认证配置，而不需要触动其他任何应用。这在实际迁移中是巨大的优势。

多租户是另一个值得说的设计。MaxKey支持多租户模式，这意味着你可以用一套MaxKey实例服务多个组织，每个组织的用户、应用、策略都是隔离的。这对于SaaS服务商和集团型企业来说是刚需。你可能会说Keycloak也支持多租户，但它的多租户实现是基于Realm的，每个Realm是完全独立的，无法共享配置。而MaxKey的多租户是基于组织的，可以在共享基础设施的同时保持数据隔离。这种设计更符合国内企业的实际需求。

多因素认证：不是可选项，是必答题

这里我要说一个可能会引起争议的观点：在2026年，如果你的企业系统还没有启用多因素认证（MFA），那基本等于在裸奔。密码泄露已经不是“是否会发生”的问题，而是“什么时候发生”的问题。每年因为密码泄露导致的数据泄露事件数以千计，而其中大部分只需要一个简单的MFA就能避免。

MaxKey的MFA方案比较灵活，支持短信验证码、TOTP动态口令（就是你用的谷歌认证器那种）、钉钉/企微扫码确认、人脸识别等多种因素组合。而且它可以根据不同的应用和用户组设置不同的认证策略。比如，普通员工登录OA只需要密码 + 短信验证码，但财务人员登录财务系统就需要密码 + TOTP + 人脸识别。这种粒度的策略控制，在很多国外方案里是不太容易做到的。

还有一个很实用的功能：访问风险评估。MaxKey可以根据用户的登录IP、设备、时间、地理位置等因素动态调整认证策略。比如，员工在公司内网登录可能只需要密码，但从境外IP登录就会自动触发MFA。这种“风险自适应”的能力，在安全和体验之间找到了平衡点。

💬 你们公司启用MFA了吗？用的什么方案？员工抱怨声大不大？

SCIM同步：离职一键关账号，这个功能值一万块

前面说了，员工离职后账号没关干净是常态。这个问题的根源在于：很多系统的账号是手动创建的，没有和人事系统打通。员工入职的时候，IT人员手动开账号；员工离职的时候，人事部门通知IT部门，IT部门再手动关账号。但现实是，这个通知链路经常断裂——人事忘了通知、IT忘了关闭、或者关闭了主系统但忘了关子系统。

SCIM（System for Cross-domain Identity Management）就是解决这个问题的标准协议。简单说，它让你的身份管理系统和其他所有系统之间建立了一个自动化的用户同步通道。当HR系统里新建了一个员工，MaxKey自动在所有关联系统里创建账号；当HR系统里标记了员工离职，MaxKey自动禁用所有系统的账号。这个功能的价值，不是用技术指标能衡量的，而是用“避免了多少安全事故”来衡量的。

MaxKey对SCIM 2.0的支持是原生的，不需要额外开发。而且它还支持基于定时任务的同步模式，即使目标系统不支持SCIM，也可以通过定时同步的方式实现用户数据的一致性。这种“标准 + 实用”的双重保障，是我觉得MaxKey设计得最用心的地方之一。

管理后台：不是最漂亮的，但是最好用的

先看图，这是MaxKey的管理后台界面。说实话，它不是最漂亮的——没有Keycloak那种现代化的Material Design风格，也没有Auth0那种精致的仪表盘。但它有一个更重要的特点：好用。每个功能的位置都在你预期的地方，不需要你去翻文档才能找到配置入口。这种“不需要学习就能用”的体验，在企业场景下比什么UI设计都重要。

特别提一下报表功能。MaxKey内置了登录日志、审计日志、会话统计等报表，这在安全审计的时候特别有用。你可能觉得这不是什么高端功能，但当你真正需要查“某个用户在某个时间段登录过哪些系统”的时候，你会感谢这个功能的存在。很多商业方案把这种功能放在付费版里，而MaxKey开源版就有。

实战踩坑：那些文档不会告诉你的事

说完了优点，说说坑。这篇文章如果只说好的不说坑，那就是广告，不是分享。

坑一：文档还是不够完善

MaxKey的文档比起几年前已经进步很多了，但和Keycloak的文档体系相比，还是有差距。尤其是一些高级功能的配置，比如自定义认证流程、复杂的权限策略配置，文档里往往只有基本说明，缺少完整的示例。不过这个问题有一个补救方案：MaxKey的微信社区群非常活跃，很多问题直接在群里问就能得到解答。这种“文档不够，社区来凑”的模式，在国内开源项目里其实是很常见的。

坑二：生态还是小了点

这是客观事实。MaxKey的第三方集成插件还不够丰富，和Keycloak那种有整个市场的插件生态比不了。不过，这也是国内开源项目的通病——生态建设需要时间和人力，而且往往是指数级增长的。好消息是，MaxKey的社区活跃度在国内开源项目里算是第一梯队的，提交的PR和Issue响应速度都很快。如果你愿意贡献，这个生态会越来越好。

坑三：国产开源的“信任问题”

这可能是最敏感的一个话题。我在技术评审的时候，有人直接问：“国产开源能保证安全吗？”我的回答是：开源的安全性不取决于国籍，而取决于代码质量和审计机制。MaxKey的代码是开源的，任何人都可以审计。而且它已经通过了很多企业的生产环境验证，包括一些大型金融机构和政府部门。如果你还是不放心，可以自己做代码审计，或者购买商业版的安全服务。但请不要因为“国产”两个字就先入为主地否定，这和“因为是外国的所以更安全”一样荒谬。

💬 你怎么看国产开源的安全性？你会因为“国产”标签而对一个开源项目产生偏见吗？

一键到达：应用中心的体验

还有一个很贴心的功能要说：应用中心。登录之后，用户看到的不是一个空白页面，而是一个包含所有已授权应用的中心页面。点一下就能直接跳转到目标系统，不需要再输入账号密码。这个体验和你用的那些企业协作平台（比如钉钉、飞书）的应用市场很像，但它是在你自己的地盘上跑的。

这个功能看似简单，但实际上解决了一个很大的痛点：员工不知道自己有权限访问哪些系统。以前的做法是给员工发一个文档，里面列了所有系统的链接和账号。现在呢？登录应用中心，能看到的就是你有权限的，看不到的就是你没权限的。简单、直接、不用猜。

什么时候不该选MaxKey

如果这篇文章只说优点不说缺点，那就是软文。以下是我认为不适合选MaxKey的场景：

纯海外业务：如果你的用户主要在海外，需要对接Google、Microsoft、Okta等海外身份服务，那Keycloak或Auth0确实更合适。MaxKey的优势在于国内生态，不是国际化。

超大规模分布式场景：如果你的系统有数百个微服务、数十万并发用户，需要复杂的分布式会话管理和全局负载均衡，那可能需要基于Keycloak或商业方案做更深入的定制。MaxKey在单集群场景下表现很好，但在超大规模分布式场景下还没有充分验证。

团队纯Java技术栈但对Spring Boot不熟悉：MaxKey基于Spring Boot构建，如果你的团队对Spring Boot生态不熟悉，二次开发和定制会有一定门槛。不过这个问题在国内Java开发者中并不普遍，毕竟国内Java生态就是Spring的天下。

需要极度定制化的认证流程：如果你的认证流程非常特殊，比如需要复杂的多步骤审批流程、动态权限变更审批等，可能需要在MaxKey基础上做较多的二次开发。这时候你需要衡量的是：在MaxKey上二次开发的成本，和从零开发一套认证系统的成本，哪个更低。大多数情况下，前者更低。

开源地址与社区

如果你看完这篇文章有点心动，以下是你需要的链接：

GitHub：https://github.com/dromara/MaxKey

Gitee：https://gitee.com/dromara/MaxKey

官网：https://www.maxkey.top

文档：https://www.maxkey.top/zh/

建议你先用Docker快速跑一个实例体验一下，然后再决定要不要深入了解。一个docker run命令就能拿到一个完整的SSO环境，这个门槛已经低到了极点。

最后说几句

这篇文章不是要说MaxKey完爆了Keycloak，也不是说所有人都应该用MaxKey。技术选型从来不是非此即彼的事。但我想说的是：在国内企业的场景下，MaxKey的“开箱即用 + 本土化 + 社区响应”这三个优势，是实实在在能感受到的。很多时候，技术方案的成败不在于它有多强大，而在于它能不能在你的具体场景下快速落地。

最后，我想抛出几个问题，欢迎在评论区讨论：

💬 你觉得国产开源的天花板到了吗？还是说只是“能用”的水平？

💬 如果你现在要重新选择SSO方案，你会选谁？为什么？

💬 你觉得企业级开源软件最重要的是什么？是功能、文档、社区、还是商业支持？

以上就是我的真实体验。你可以不同意我的观点，但如果你有不同的经历或者见解，请务必在评论区分享。技术讨论不需要共识，但需要真实。