公司系统一多，登录就容易变成一团乱麻。
内部管理后台一套账号，客户门户一套账号，老系统依赖 LDAP，新应用使用 OIDC，合作伙伴又要求 SAML。员工离职后，管理员甚至不确定还有哪些入口没关。
大家真正缺的，往往不是“再做一个登录页”，而是一个统一的身份入口。
开源项目 Casdoor 就在解决这件事。截至 2026 年 7 月 21 日，它在 GitHub 上约有 1.4 万 Star，最新版本 v3.119.0 发布于 7 月 17 日。项目采用 Apache-2.0 许可证，支持自托管，并覆盖 OAuth 2.0、OIDC、SAML、CAS、LDAP、SCIM、WebAuthn、TOTP、MFA 和 RADIUS 等一长串身份协议。
但如果你只把它理解成“开源登录页”，就低估了它。
它解决的不是登录，而是身份碎片化
Casdoor 是一套 UI-first 的 IAM 与 SSO 平台。简单说，它把用户、组织、应用、身份提供方和登录策略集中到一个可视化控制台里。
每个需要保护的服务，都可以在 Casdoor 中注册为一个 Application。组织内的用户完成一次登录后，就能访问被授权的多个应用；不同应用还可以分别决定是否开放密码登录、GitHub、Google、微信等第三方登录，以及注册时需要填写哪些字段。
这意味着，新系统不用继续自己保存密码、发送验证码、开发忘记密码页面。旧系统也不一定要推倒重来，可以根据现有能力选择 SAML、CAS、LDAP 或其他方式接入。
它更像一座“身份转换站”：前面接人和组织，后面接新旧应用，中间用标准协议传递身份。
协议多不是为了炫技，而是为了接住现实
理想世界里，所有应用都支持最新的 OIDC；现实世界里，企业系统跨越了十几年。
新开发的 Web 或移动应用，通常优先用 OAuth 2.0 / OIDC；不少企业软件使用 SAML；校园与老牌系统可能依赖 CAS；内部目录仍可能运行 LDAP 或 Active Directory；人员生命周期同步又会用到 SCIM。
Casdoor 的价值，是把这些协议放在同一个管理面里。它既能作为身份提供方，也能连接外部身份源。以 SAML 为例，服务提供方可以从 Casdoor 的 Metadata URL 获取 SSO 地址、Issuer 与证书，再根据需要映射用户属性。
不过，支持某种协议不等于所有软件都能“点一下就接好”。回调地址、证书、属性映射、Token 生命周期与退出登录行为，仍然需要逐个应用验证。
登录成功，不代表权限问题已经解决
这是身份平台最容易被混淆的地方。
认证回答“你是谁”，授权回答“你能做什么”。Casdoor 除了完成登录，还借助 Casbin 管理 ACL、RBAC、ABAC 等权限模型。
团队可以围绕用户、角色、资源和动作建立策略。例如，销售可以读取客户资料，财务可以审批退款，外包人员只能访问指定项目。对于复杂场景，还可以定义更细的动作—资源组合。
但要注意：在 Casdoor 里配置了 Permission，并不代表你的业务接口会自动受到保护。外部应用仍需调用 Casbin API 或在自己的服务端执行鉴权。否则控制台里策略写得再漂亮，真正的接口也可能照样放行。
这条边界很重要：Casdoor 提供身份与策略能力，业务系统负责在正确的位置执行它。
从“人登录应用”，走向“Agent 调用工具”
2026 年的 Casdoor 又多了一层新定位：Agent-first IAM 与 MCP 网关。
官方文档已经提供 MCP server、OAuth 鉴权、scope 控制和工具调用说明，也支持将应用分类为面向用户的普通应用，或面向机器到机器调用的 Agent 应用。Agent 类应用可以使用 MCP 或 A2A 类型，并定义自己的 scopes。
这背后的问题其实很现实：过去访问系统的主要是人，现在 AI Agent 也需要读取应用、调用工具和执行操作。它不能拿着一个永不过期的超级密钥到处跑，而应该像用户一样拥有身份、授权范围、过期时间和审计记录。
Casdoor 想做的，是把多年积累的人类身份协议，延伸到 AI Agent 的访问控制上。这个方向值得关注，但生产使用前仍应逐项检查 scope 粒度、Token 撤销、日志、密钥轮换和工具侧强制鉴权。
五分钟跑起来，不等于可以直接上线
Casdoor 提供 Docker、Docker Compose 和 Kubernetes 部署路径。体验版 casdoor-all-in-one
内置 SQLite，一条命令就能启动；标准镜像则可以连接 MySQL、PostgreSQL、SQL Server 等数据库。
这种低门槛很友好，也很容易制造错觉。
官方明确说明 all-in-one 只适合试用，不适合生产。示例默认管理员账号是 built-in/admin
，密码是 123
，上线前必须立即更换。生产环境还应通过 Nginx、Traefik 或 Caddy 配置 TLS，并处理数据库高可用、备份恢复、监控告警、邮件与短信 Provider、MFA、管理员权限和安全升级。
身份系统是所有应用的“总钥匙”。它一旦不可用，所有接入系统都可能无法登录；它一旦被攻破，攻击者拿到的也不只是一个应用。因此，Casdoor 的部署评审应该比普通后台服务更严格。
哪些团队适合试一试？
Casdoor 比较适合这些场景：
○ 同时维护多个内部系统，希望统一账号和登录入口；
○ 新旧应用协议混杂，需要 OIDC、SAML、CAS、LDAP 等兼容层；
○ 希望自托管身份数据，并有能力承担安全运维；
○ 需要用 Casbin 表达 RBAC、ABAC 等细粒度权限；
○ 正在建设 MCP 或 Agent 平台，需要统一 OAuth 与 scope 管理。
如果团队没有身份协议经验，也没有人负责证书、密钥、升级、审计和故障恢复，那么先使用成熟的托管身份服务，往往更稳妥。开源带来的是控制权，不是自动得到安全结果。
最后：先接三个系统，再谈全面替换
评估 Casdoor，不妨选三种不同应用做 PoC：
1. 一个新应用，用标准 OIDC 接入；
2. 一个旧系统，用 SAML、CAS 或 LDAP 接入；
3. 一个内部 API 或 MCP 工具，验证 scope 与服务端鉴权。
测试时别只看“能不能登录”，还要演练账号禁用、Token 过期、单点登出、MFA 恢复、证书轮换、备份恢复和 Casdoor 故障时的应急方案。
真正成熟的统一身份系统，不是让登录页看起来更整齐，而是让每个身份、每次访问和每项权限都能被管理、撤销与追踪。
你们团队现在有多少套账号体系？最难统一的是新应用，还是历史系统？欢迎在评论区聊聊，也别忘了点个“在看”。
参考资料/来源
Casdoor GitHub 仓库：https://github.com/casdoor/casdoor
