Casdoor 如何統一管理 SSO、權限及 AI Agent 身份驗證
账号一多就像在裸奔？13.7k Star Casdoor 用一扇“身份门”管住 SSO、权限和 AI Agent
Casdoor 是可自行部署的 IAM/SSO 服務端，將用戶、組織、應用及第三方身份源集中管理，並支援 SSO、權限策略與多種認證協議。它亦提供 MCP Gateway、A2A 等面向 AI 應用的能力，適合需要統一管理多個系統登入，或部署 Agent、MCP Server 的團隊。身份與令牌由 Casdoor 管理，業務系統仍須自行落實資源權限。
2026-10-23 13
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
嗨，我是小华同学，专注解锁高效工作与前沿AI工具！每日精选开源技术、实战技巧，助你省时50%、领先他人一步。👉免费订阅，与10万+技术人共享升级秘籍！
真正让账号体系失控的，往往不是密码不够复杂，而是每个系统都在各管一套用户、登录方式和权限。
Casdoor 不是又一个登录页面，而是一扇放在所有应用前面的“身份门”。一次认证后，把 SSO、组织、身份源、权限策略与审计线索收进一个入口。
这篇用 3 分钟讲清：它解决什么、适合接在哪里，以及为什么做 AI 应用的团队也该关注它。
上图是官方 Demo 登录页使用的项目标识。当前仓库没有可复用的产品截图，后文用主题场景图和白板图补足“为什么需要它、怎么流转”的理解缺口。
一堆系统各自登录，和一套统一身份入口，后期维护是两种完全不同的难度。
最容易被低估的，是“账号散装化”
项目刚开始时，自己写一套登录很快：用户表、JWT、找回密码，再接一个第三方登录，看起来就够了。
但当后台、客户门户、内部工具、移动端、MCP 服务逐渐出现，麻烦也跟着变形：用户是谁、从哪里来、能进哪个应用、离职后怎么回收、登录记录去哪查，开始散落在不同项目里。
这时继续复制登录模块，不是在省时间，而是在积累以后最难盘点的安全债。
| 你遇到的情况 | Casdoor 想收住的事 |
|---|---|
| 每个系统都有独立账号 | 把用户、组织和应用集中到 Web 控制台 |
| 用户反复登录多个应用 | 用 SSO 让一次登录在同一组织内复用 |
| 既要企业目录又要社交登录 | 对接 LDAP、OAuth 身份源等 provider |
| 权限规则越写越散 | 结合 Casbin 表达 ACL、RBAC、ABAC 等策略 |
| AI 工具和 MCP 服务也要鉴权 | 提供 MCP Gateway、A2A 等面向 AI 应用的能力 |
Casdoor 到底是什么？
一句人话：它是可以自己部署的 IAM/SSO 服务端，负责“确认你是谁”和“把你安全地交给应用”。
仓库定位很明确：Casdoor 有自己的 Web 管理界面，不是只在反向代理前补一层拦截；用户、组织、应用与第三方身份源都能放在同一处配置。它支持 OAuth 2.0 / OIDC、SAML、CAS、LDAP、SCIM、WebAuthn、TOTP/MFA 等常见协议与认证方式。
对开发者来说，关键不是背完这些缩写，而是少从零发明一遍“登录体系”。你的应用可以按标准协议接入，用户登录和令牌签发交给身份服务处理，再在业务侧继续做自己的领域权限判断。
把“各自为战的登录”变成“一个身份入口”，这是 Casdoor 最容易理解、也最实用的价值。
它的亮点，不止是 SSO
第一，协议覆盖足够宽。新系统常用 OIDC；企业客户可能要求 SAML；老系统还会遇到 LDAP、CAS。Casdoor 的价值是在同一身份平台里处理这些入口，而不是让每个业务系统各自兼容一轮。
第二，认证和权限管理能接上。它能管理用户、组织和应用，并与 Casbin 的 ACL、RBAC、ABAC 等授权模型衔接。通俗说，前者解决“你是谁”，后者帮助表达“你能做什么”。
第三，AI 产品多了一个更严肃的入口。当前仓库把 MCP Gateway、A2A 放进了能力列表。对准备把 Agent、MCP Server 接给团队或客户的项目来说，身份、令牌和权限边界不能再当成上线后的补丁。
第四，接入路径相对完整。项目提供 Go、Java、Python、Node.js 等 SDK/API 思路，也有 Docker、Compose、Helm 等部署路径。先跑官方 Demo 看模型，再决定是否进入正式集成，会比直接把认证逻辑埋进业务代码稳妥得多。
一次登录，背后实际发生了什么？
别把 SSO 想成“点一下就自动登录”的魔法。它更像一条标准的交接链：用户在身份入口完成认证，Casdoor 根据配置生成可信令牌或断言，应用再验证它，并在自己的业务范围内放行。
最重要的分工：Casdoor 管身份与令牌，业务系统仍要负责自己真正的资源权限。
这也是它比“每个项目复制一套 JWT 登录”更值得关注的原因：认证流、身份源、组织和审计可以被统一治理，但业务授权不会被粗暴地抹平。
哪些团队值得先收藏？
| 场景 | 为什么值得看 |
|---|---|
| 有多个内部系统的研发团队 | SSO 能减少重复账号与登录流程 |
| 做 B 端、多租户 SaaS 的团队 | 组织、用户和应用能放进同一身份模型 |
| 需要对接企业客户身份系统 | OIDC、SAML、LDAP、SCIM 让协商不必从零开始 |
| 正在发布 MCP 或 Agent 服务的团队 | 先把人、应用、令牌和权限边界想清楚 |
| 想自托管身份体系的开发者 | 可以掌握部署、配置与数据边界 |
但别把它当成“一键安全”
身份系统是关键路径，能集中治理，也意味着需要更认真地治理。
如果只有一个很小的单体应用、没有跨系统登录需求，先引入完整 IAM 平台可能比简单认证更重。反过来，如果应用本身没有正确校验令牌、没有在业务侧落实资源权限，再好的 IdP 也救不了越权问题。
正式上线前，至少要做这些基础动作：更换任何默认凭据、启用 HTTPS 与合适的 MFA、规划密钥和令牌轮换、备份数据与配置、设置审计和告警，并跟进安全更新。对可用性要求高的团队，还要按关键基础设施思路设计备份与高可用，而不是只把它当一个普通后台。
Casdoor 的吸引力不在于又多了一个“登录 SDK”，而在于它把身份这件原本容易散掉的事，变成了一套能看见、能配置、能演进的基础设施。
这篇先做开源项目速览。后续我会继续拆：怎么用 OIDC 把一个前后端分离项目接进 Casdoor、SSO 到底要改哪些回调，以及 Agent/MCP 服务的鉴权边界应该怎么划。
项目地址
來源：阿里雲開發者社區 AI · developer.aliyun.com