一个组织只要稍微上点规模，账号就会散得到处都是：OA 一套、邮箱一套、代码仓库一套、CI 一套、监控一套、报表又一套。人入职时要挨个开，离职时要挨个关，漏掉一个就是一颗雷；密码策略各自为政，审计想查「谁在什么时候进了哪个系统」更是拼不拢。MaxKey 做的就是这件事——把这些系统接到同一个认证中心上，一次登录，处处通行。
Dromara MaxKey 是开源的单点登录认证系统，定位 IAM / IDaaS 身份管理与认证产品，名字取「马克思的钥匙」的谐音，寓意一把万能钥匙。它遵循 Apache License 2.0，源码托管在 Gitee（同时镜像到 GitHub、GitCode），是 Gitee 最有价值开源项目（GVP），仓库已有 15.1K Star、1.8K Fork。当前发布版本为 v4.2.0，2026 年 10 月更新。官方给的应用场景是医疗、金融、政务、制造这类系统多、合规要求重的行业。
能力边界：协议与登录方式
判断一个 SSO 产品能不能用，先看它认哪些协议。MaxKey 把支持程度自己分了三档，这份清单比一句「支持主流协议」实在得多：
| 协议 | 支持程度 | 典型对接对象 |
|---|---|---|
| OAuth 2.x / OpenID Connect | 高 | 自研 Web / 移动应用、第三方 SaaS |
| SAML 2.0 | 高 | 企业级商业软件、云服务平台 |
| JWT | 高 | 前后端分离、微服务间信任传递 |
| CAS | 高 | 高校与老一代 B/S 系统 |
| SCIM 2.0 | 高 | 跨系统用户目录同步 |
| FormBased、TokenBased（Post / Cookie） | 中 | 没有标准协议的老系统 |
| ExtendApi、EXT | 低 | 需要自行扩展的特殊场景 |
登录侧同样列得很细，几乎把企业里能想到的入口都覆盖了：
| 登录方式 | 官方支持范围 |
|---|---|
| 动态验证码 | 字母 / 数字 / 算术 |
| 双因素认证 | 短信 / 时间令牌 / 邮件 |
| 短信认证 | 腾讯云短信 / 阿里云短信 / 网易云信 |
| 时间令牌 | Google / Microsoft Authenticator、FreeOTP，支持 TOTP 与 HOTP |
| 域认证 | Kerberos / SPNEGO / AD 域 |
| 目录服务 | OpenLDAP / Active Directory / 标准 LDAP |
| 社交账号 | 微信 / QQ / 微博 / 钉钉 / Google / Facebook 等 |
| 扫码登录 | 企业微信 / 钉钉 / 飞书 |
| 无密码登录 | WebAuthn FIDO2 / passkey |
这里有个值得留意的点：从动态验证码、TOTP 一路到 AD 域、LDAP 与 passkey，说明它不是只做「网页跳转登录」的轻量组件，而是打算把企业现有的身份源一起接进来。FormBased 和 TokenBased 那两档「中」也很重要——老系统往往改不动，能靠表单代填和令牌传递接进来，落地阻力会小很多。
登录之后看到什么
认证中心登录后是一个应用门户，所有已授权的系统以卡片形式铺开，点一下直接跳转，不再重复输密码。官方演示里接了人力资源系统、Jira、GitLab、Jenkins、JumpServer、Nacos，以及 OAuth2 / OIDC / CAS / JWT / SAML 等各种协议的 Demo 应用。
登录页本身相当朴素：账号密码加验证码，下方一排第三方登录图标，页脚标注版本与 Apache 2.0 许可。没有花哨的东西，这类基础设施界面越克制越好。
管理端：账号、应用、审计三件事
SSO 的价值一半在登录，另一半在管理。MaxKey 把身份管理（IDM）、认证（AM）、单点登录、RBAC 权限与资源管理放在同一套后台里，几个关键能力：
- 用户生命周期：支持 SCIM 2 协议，开箱即用的连接器负责身份供给同步，入职、调岗、离职的账号变更可以往下游系统推。
- 目录与密码：简化 AD 域控、标准 LDAP 的组织与账号管理，提供密码自助重置。
- 多租户：集团下多家企业独立管理，或企业内不同部门做数据隔离。
- 策略与审计：密码策略、访问策略可配置；接 Ip2region 或 GeoLite2 做 IP 定位，覆盖用户全生命周期审计、访问行为追溯、合规审计与风险预警。
- 平台覆盖：Web、iOS、Android 等终端，认证能力从 B/S 延伸到移动应用。
用户管理是典型的左侧组织树、右侧账号列表：登录账号、姓名、工号、部门、职位、状态一目了然，组织层级可以直接展开。
应用管理里每条记录对应一个接入系统，带协议类型、编码、分类、排序与启用状态——接入一个新系统，本质就是在这里建一条配置并把协议参数对齐。
访问报表是我觉得最容易被低估的一块：当日与 30 日访问趋势、按 IP 段统计的地域分布、按应用和浏览器分别汇总的访问量，都在同一页。合规检查、异常登录排查的时候，这类现成报表能省掉大量自己写 SQL 的工夫。
技术栈与版本
基于 Java EE 平台、微服务架构，用 Spring、MySQL、Tomcat、Redis 这套常见组合，扩展性主要靠这套主流栈撑着。README 上的环境徽章标的是 JDK 21+ 与 MySQL 8.4+，动手前先把这两项对齐，别拿老环境硬装。
协议上要注意版本维护节奏：官方对每个发行版提供约一年技术支持，到期即 EOL。下载页把 4.1.x 的历史版本按支持周期列了出来，明确提醒 EOL 版本要及时升级。生产环境选版本时，别只挑「能跑起来」的那个，优先选仍在支持周期内的。
最快的上手路径
官方文档给了 Windows、Linux、Docker、Docker Compose、Rainbond、宝塔几条路，最省事的是 Compose：
# 1. 从仓库取出官方配置目录 deployment/docker
# https://gitee.com/dromara/MaxKey/tree/main/deployment/docker
# 把整个目录放到服务器的 /root 下
# 2. 进入目录并启动
cd /root/docker
docker-compose up --build -d
镜像来自官方 Docker Hub 账号 maxkeytop，配置文件里已经编排好 MaxKey 与依赖组件，不用自己一个个拼。起完之后的访问地址与初始化步骤在官方文档的「应用访问」页。想省掉编译环节，也可以直接用官方发行版（Windows 版走网盘分发），但生产环境我更建议走容器、把配置纳入版本管理。
几条上线前的老实话：认证中心是全站信任根，务必放在 HTTPS 之后、限制管理后台的访问来源；MySQL 与 Redis 不要暴露到公网；初始化后立刻改掉默认管理员口令；密码策略、会话超时、双因素认证按组织要求先配好再放量。这些跟产品本身无关，但恰恰是这类系统最容易出事的地方。
我的一点判断
MaxKey 适合的画面很具体：内部系统超过五六个、有明确等保或审计要求、账号数据已经在 AD / LDAP 里、且有人愿意长期维护。它把协议适配、目录同步、审计报表这些重复劳动做成了产品，比每个系统各自实现一套登录划算得多。
反过来，如果只有一两个系统、团队三五个人，引入一套 IAM 带来的运维成本可能比省下的登录时间还多。另外要清醒：真正的工期不在装服务——Compose 一条命令就起来了——而在应用侧改造和账号数据治理。哪些系统能改协议、哪些只能走表单代填、历史账号怎么去重、离职回收链路能不能真正闭环，这些才是决定项目成败的部分。
顺带说明，上面几张官方截图里的姓名、应用清单与访问数据都是产品演示数据，不是真实组织的信息；界面里出现的第三方产品图标只是展示「可接入哪些系统」，并非推广。
小结
国产开源、Apache-2.0、协议覆盖完整、管理端功能齐、有活跃社区和明确的版本支持周期——对想自建统一身份入口的团队，MaxKey 属于少数可以直接放进选型清单认真评估的方案。它属于 Dromara 社区，社区主打微服务与云原生方向的开源共建。先看协议清单对不对得上现有系统，再花一个下午用 Compose 起一套跑通，比读十篇介绍管用。
本文整理自公开资料并做重写，原始出处：https://gitee.com/dromara/MaxKey。文中配图已去除站点叠加水印与推广信息；版权归原作者所有。