Casdoor 评测：一个把 MCP 网关装进 IAM 服务器的 Go 身份平台
An open-source Agent-first Identity and Access Management (IAM) /LLM MCP & agent gateway and auth server with web UI supporting OpenClaw, MCP, OAuth, OIDC, SAML, CAS, LDAP, SCIM, WebAuthn, TOTP, MFA, Face ID, Google Workspace, Azure AD
秒懂
- 它是什么？
- Casdoor 是 Go 写的自托管身份与访问管理服务器，支持 OAuth、OIDC、SAML、LDAP、SCIM，并在 2026 年加入 MCP 与 Agent 网关能力。本文基于仓库材料分析它的定位、运行方式与适用边界。
- 适合谁用？
- 如果你是运维一个需要多种协议共存的用户目录（比如同时服务 SPA 和遗留 CAS 应用）的团队，Casdoor 值得认真评估。它把组织、应用、认证方式全部放进 Web 控制台，省去改配置重部署的循环，而且单二进制加数据库就能跑，没有 JVM 或 Kubernetes 的负担。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
Casdoor 到底解决什么问题
Casdoor 把自己定位成完整的身份提供方，不是认证代理，也不是嵌入应用的库。它自己存用户、发令牌、提供管理后台，应用可以完全把登录丢给它，自己从不接触密码。这跟一堆只做转发或只做登录框的轻量工具划清了界限。README 里那句「complete identity provider」是关键：你要拥有用户目录本身，而不是把认证外包给某个中间层。它的目标用户是那些需要同时服务现代 SPA 和遗留应用的团队，比如既有 OIDC 前端又有 CAS 老系统的组织。一个 Casdoor 实例能同时用多种协议输出同一套账号，省掉为每个协议单独维护用户库的麻烦。
多协议与 Casbin 授权：机制不是堆功能
Casdoor 的核心机制是「一个用户目录，多协议出口」。OAuth 2.0、OIDC、SAML 2.0、CAS、LDAP、SCIM 都指向同一批用户数据，应用按自己的习惯选协议接入。授权部分用的是 Casbin，支持 ACL、RBAC、ABAC 和自定义模型，不是写死的权限方案。这意味着你可以用一套用户体系同时支撑不同安全级别的应用。README 强调所有配置都在 Web 控制台里改，组织、应用、提供方、登录方式、邮件和短信模板、登录页品牌都能在界面上调整，不需要改配置文件再重新部署。这个设计取舍很明显：灵活性和可操作性优先，但代价是把配置状态放在数据库里，而不是代码仓库里，版本管理和审计就得靠数据库备份或导出机制来补。
Agent 与 MCP 网关：新标签，旧材料
仓库描述里写着「Agent-first IAM」和「LLM MCP & agent gateway」，主题标签也有一串 agentic-ai、mcp-gateway、openclaw。但翻遍 README 清理后的内容，找不到任何关于 MCP 网关如何工作、Agent 身份怎么验证、OpenClaw 怎么接入的说明。没有协议流程，没有配置示例，没有架构图。最近几个版本 v4.1.0 到 v4.3.0 在 2026 年 9 月密集发布，说明这块功能在快速迭代，但文档明显没跟上。如果你冲着 MCP 网关来，得先去 casdoor.ai 的文档挖细节，或者直接翻源码。这个落差本身就是一个判断点：Casdoor 的传统 IAM 部分成熟，Agent 网关部分还处于「标签先行、材料滞后」的状态。
30 秒起跑：all-in-one 镜像的诱惑与陷阱
README 给了最快的体验路径：`docker run -p 8000:8000 casbin/casdoor-all-in-one`。这个镜像内置 SQLite 和示例数据，启动后访问 http://localhost:8000，用组织 `built-in`、用户名 `admin`、密码 `123` 登录。它特意提醒登录表单有独立的组织和用户名字段，文档里写的 `built-in/admin` 是同一回事，不是带斜杠的用户名。这个镜像明确标注「不用于生产」，数据存在容器内，容器删除数据就消失。这是评估用的玩具，不是部署方案。想试的人要注意 demo.casdoor.com 是可写的，但数据大约每 5 分钟重置一次；door.casdoor.net 是只读的，所有写操作会故意失败。这两个 demo 适合点界面，不适合做任何持久化测试。
生产部署路径：docker-compose 的源码构建代价
生产路径是仓库里的 docker-compose.yml，它把 Casdoor 和 MySQL 8 一起启动。但 README 明确警告两件事：第一，compose 会从源码构建镜像，包括 Go 后端和 React 前端，第一次 `docker compose up` 要花好几分钟，不是快速试用路径；第二，你得先把 Casdoor 指向捆绑的数据库。这个设计意味着你没法像拉现成镜像那样秒级起步。对生产环境来说，从源码构建反而给了你定制和审计的机会，但代价是部署流程变长。README 提到「Set the M」就截断了，后面的步骤需要去官方文档补全。如果你习惯基础设施即代码，这个从源码构建的路径可能正合口味；如果你只想快速跑一个稳定版本，得权衡构建时间和镜像维护成本。
维护成本与许可边界
Casdoor 用 Go 写，单二进制加数据库就能跑，没有 JVM、没有 operator、不需要集群，这对运维是实打实的减负。升级路径从仓库看是常规的 release 节奏，v4.1.0 到 v4.3.0 间隔只有几天，说明项目处于活跃开发期，版本迭代快。快节奏意味着新功能来得快，但也意味着升级时要多留意 changelog，尤其是 MCP 网关这类新模块可能有不兼容变更。许可证是 Apache-2.0，这是宽松许可证，允许商用和修改，但你不该把它当法律建议，具体合规要问律师。配置全部存在数据库里，这意味着升级代码版本时，数据库结构迁移是主要风险点，得在测试环境先跑一遍迁移再上生产。
替代方案与选型判断
README 自己点出了一个替代方向：如果你只需要在反向代理前加一个登录屏，更小的工具可能更合适。这类工具包括 oauth2-proxy 或 authelia，它们不做用户目录，只做认证转发，适合保护内部工具，但不适合需要真正管理用户账号的场景。Casdoor 的差异在于它把用户存储、令牌签发、管理界面都包了，是一个完整的 IdP。另一个替代是云托管的身份服务，比如 Auth0 或 Okta，它们省去自托管运维，但你要把用户数据交给第三方，而且按量计费。Casdoor 适合对数据主权有要求的团队，愿意自己维护一个 Go 服务和数据库。选型时要先问自己：你需要的是用户目录还是登录闸门？需要多协议共存还是单协议够用？能接受数据库里的配置作为唯一事实来源吗？这三个问题能帮你过滤掉大部分错误选择。
编辑结论
如果你是运维一个需要多种协议共存的用户目录（比如同时服务 SPA 和遗留 CAS 应用）的团队，Casdoor 值得认真评估。它把组织、应用、认证方式全部放进 Web 控制台，省去改配置重部署的循环，而且单二进制加数据库就能跑，没有 JVM 或 Kubernetes 的负担。反过来，如果你只需要在反向代理前加一个登录页，Casdoor 是过重的工具，README 自己也承认这一点。MCP 网关和 Agent 身份是新增卖点，但仓库材料里没有给出任何协议细节或配置示例，别把它当成现成的 Agent 安全方案。动手验证的第一步是跑 `docker run -p 8000:8000 casbin/casdoor-all-in-one`，用 `built-in` / `admin` / `123` 登录，然后检查你要接的客户端是否支持 OIDC 的 discovery 端点，以及 MCP 网关的接入方式是否匹配你的 Agent 框架。注意这个 all-in-one 容器把数据放在容器内，容器一删数据就没了，只适合评估。生产部署请走 docker-compose 的 MySQL 路径，但要知道它从源码构建镜像，首次启动要等几分钟。
社区笔记