企业里最难收拾的从来不是某台服务器，而是账号：每上一套系统就多一份用户表、多一套密码策略、多一处离职后没关掉的入口。单点登录（SSO）这件事因此常年有人做，但多数方案要么太重，要么只解决「登录」不解决「谁有什么权限」。
Casdoor 是 Casbin 团队做的开源身份与访问管理平台，Apache-2.0 协议，GitHub 上约 1.48 万星。它这两年的定位有点意思：从一个带 Web 控制台的 SSO 服务，往「连 AI 智能体一起管」的方向长。这篇按公开资料重新梳理一遍它到底能做什么、怎么最快跑起来、以及什么情况下别选它。
一、它不是「给现有系统加个登录框」
官方 README 里有一句界定得很清楚：Casdoor 是一个完整的身份提供商（IdP），不是认证代理，也不是嵌进代码里的库。用户数据存在它这里，令牌由它签发，应用把登录整个交出去，自己不再碰密码。
这个区别决定了选型。如果你只是想在网关前面加一层登录页，用更轻量工具就够了；但如果你希望「用户目录归我、协议由我发、权限在后台点得动」，那才轮到 Casdoor 这类完整 IdP 上场。
它和上一回写过的 MaxKey 是同类，路子却不太一样：MaxKey 是 Java 体系、强调企业级协议矩阵；Casdoor 是单个 Go 二进制加一个数据库，不需要 JVM、不需要 operator、也不需要集群就能起。部署体量是它很实在的一个卖点。
二、先看用户会看到的那张脸
官方给出的登录页截图里，登录框顶部是四个并列标签：Password / Code / WebAuthn / Face ID——密码、邮件或短信验证码、通行密钥、人脸识别，用户自己切。下方是一整片第三方身份提供商图标，启用哪些就显示哪些。整个页面按组织（organization）自定义品牌与主题。
有个细节值得单独提：登录表单里「组织」和「用户名」是两个独立输入框。文档里常把默认管理员写成 built-in/admin，那只是把两个字段连写了，并不是一个带斜杠的用户名。第一次上手照着填成单个用户名，会卡在登录页上半天。
三、能力清单：协议、权限、智能体、开发接口
按官方 README 的分组重新整理成一张表，比逐条读项目符号清楚：
| 方向 | 具体能力 |
|---|---|
| 认证协议 | OAuth 2.0 / OIDC 完整授权服务器；SAML 2.0（既能当 IdP 也能当 SP）；CAS（照顾老系统）；LDAP（可从目录同步，也可对外提供目录服务）；SCIM 2.0 自动开通与回收账号 |
| 登录方式 | WebAuthn / passkeys 无密码登录、TOTP 与 MFA、邮件与短信验证码、Face ID 人脸登录，以及配套的开源 TOTP 应用 Casdoor Authenticator |
| 组织与权限 | 多租户组织隔离；角色、权限与 Casbin 策略模型（ACL / RBAC / ABAC / 自定义模型），不是写死的权限表；社交登录与自定义提供商（身份、邮件、短信、存储、支付后端都能插）；登录与管理操作审计日志 |
| AI 与智能体 | MCP gateway：把 Model Context Protocol 服务暴露出来并控制谁能访问；A2A 智能体间通信支持 |
| 开发者接口 | 后台每个操作都有对应 REST API；官方 SDK 覆盖 Go、Java、Python、Node.js、JavaScript（含 React / Vue / Angular）、.NET、PHP、Rust；Swagger UI 在线调试；Webhook 把用户与登录事件推到自有系统 |
第三方身份源方面，README 明确点名 Google Workspace、Microsoft Entra ID（Azure AD）、GitHub 等；从后面那张 Providers 设置截图能看到，国内常见的微信、QQ、企业微信、钉钉、阿里云短信、GitHub 这些也都以 provider 形式挂得上。「自定义提供商」这一层意味着不够用时可以自己接，不必等官方发版。
四、管理台：所有配置都在界面上
控制台首页把家底一次摊开：总用户数、今日 / 近 7 天 / 近 30 天新增、组织数、令牌数、应用数、提供商数，配 30 天趋势曲线、提供商占比环图、MFA 开通率、登录热力图。这类仪表盘本身不稀奇，但它说明账号状态是「可观测」的，不是散在几张表里靠 SQL 拼。
应用列表是接入侧的主界面：每个把登录委托给 Casdoor 的应用在这里建一条记录，拿到 Client ID / Client Secret，把应用侧的 OAuth 或 OIDC 客户端指过来即可。跨组织的应用统一管理，列表里能看到显示名、分类、Logo、所属组织和提供商。
最值得看的是应用设置里的 Providers 标签页：每个身份源单独控制 Can signup / Can signin / Can unlink 三个开关，还能配绑定规则。同一套用户目录，A 应用允许微信注册、B 应用只允许企业账号登录，在这里点几下就完事。
这正是官方反复强调的一点：组织、应用、提供商、登录方式、邮件短信模板、登录页品牌，全在 Web 控制台里改，不用改配置文件、不用重新部署。对运维来说，这个差别比多支持两三个协议更直接影响日常工作量。
五、30 秒跑起来，以及四条部署路径
最快的一条命令不需要数据库也不需要配置文件，用 SQLite 加示例数据把服务拉起来：
docker run -p 8000:8000 casbin/casdoor-all-in-one打开 http://localhost:8000，按下表登录：
| 字段 | 值 |
|---|---|
| Organization | built-in |
| Username | admin |
| Password | 123 |
官方提供两个在线演示：可写版数据约每 5 分钟重置一次，只读版稳定但所有写操作按设计失败，两边都是同一组演示凭据。想认真点评估，还是本地起容器靠谱。
另外三条正式路径：
- Docker Compose + MySQL 8：仓库自带 compose 文件，但要注意它是从源码构建镜像（Go 后端加 React 前端），首次启动要几分钟，不是快速试用路径。启动前得把
conf/app.conf的数据库配置改成与db服务一致：
这里写driverName = mysql dataSourceName = root:123456@tcp(localhost:3306)/ dbName = casdoorlocalhost是对的——compose 设了RUNNING_IN_DOCKER=true，Casdoor 启动时会把它改写成容器宿主机地址。entrypoint 已带--createDatabase=true，库会自动建。然后docker compose up。 - Kubernetes / Helm：
helm install casdoor oci://ghcr.io/casdoor/helm-charts/casdoor。Chart 默认不对外暴露，先kubectl get svc找服务名，再kubectl port-forward svc/<service-name> 8000:8000；正式环境改配 Ingress 与外部数据库。 - 源码开发：Go 1.26+（
go.mod实为go 1.26.0/toolchain go1.26.10）、Node.js 20 LTS、Yarn 1.x，数据库支持 MySQL、PostgreSQL、SQLite、SQL Server 等。前端yarn build后go run main.go；改前端时改用yarn start起 7001 端口热更新，另一个终端跑 Go 提供 API。
还有一条容易被忽略的路线是配置即代码：组织、应用、用户、提供商、角色、权限可以放 Git 里，启动时用 JSON / YAML 初始化；配合 initDataMerge = true 和 initDataWatchInterval = 30，文件改动会周期性重新应用且只覆盖文件里写明的字段，不用重启。官方 Terraform Provider 则通过 API 管理同一批对象，带 plan、import 和漂移检测。要管多套环境时，这比在界面上点更靠谱。
上线前必须做的几件事
这几条是官方安全小节明列的，照抄一遍：
- 改掉
admin的123——演示凭据绝不能带进生产。 - 只走 HTTPS，并把
conf/app.conf里的origin设成公网地址。 - 复查
app.conf里从示例文件继承下来的值，尤其dataSourceName和提供商密钥。 - 生产设
runmode = prod、保持showSql = false。 - 发现漏洞别提公开 issue，走项目给出的私有披露渠道。
六、技术栈，以及一处 README 与源码对不上的地方
Casdoor 是前后端分离：后端 Go + Beego 暴露 REST API，前端在 web/ 目录，数据库通过 XORM 屏蔽差异，Redis 是可选缓存——只有跑多副本时才需要。旧的 Ant Design 控制台留在 web-old/ 仅作参考，不再构建和提供服务。
有一处值得留意：README 写的是「React 18 + shadcn/ui + Tailwind CSS，Vite 构建」，但我实际拉了仓库里的 web/package.json，看到的是 react 19.3.0 / react-dom 19.3.0，Vite 5.4、TypeScript 5.7。文档这一句显然落后于代码了。要按源码部署或改前端，以 package.json 为准，别照 README 锁版本。协议倒是两边一致，LICENSE 文件确认是 Apache License 2.0。
接入侧还有个 Marketplace，里面是现成集成模板：Grafana、GitLab、Nextcloud、Vaultwarden、Argo CD、Immich、Open WebUI、Portainer、Gitea、Proxmox VE 等应用的一键 SSO，以及身份源模板、登录页主题。它创建好对象并把你的参数填好，还会给一份应用侧该填什么的说明；卸载时会清理或还原。
七、为什么它开始管 AI 智能体
仓库标题现在写的是「Agent-first IAM / LLM MCP & agent gateway」，功能里有 MCP gateway 和 A2A，目录里也能看到 mcp/、mcpself/。逻辑其实顺理成章：智能体调工具、访问数据，本质上仍然是「某个主体以什么权限访问某个资源」，只是主体从人变成了 agent。与其让每个 MCP 服务自己发明一套鉴权，不如把它们挂到统一的身份服务下，用同一套组织、角色与 Casbin 策略来管。
这是 Casdoor 目前跟传统 IAM 拉开身位的地方，但也恰恰是最该观望的部分：协议和社区实践都还在快速变动，真上生产前建议先小范围验证，别把核心登录链路和实验性能力绑在一起。
八、我的一点判断
适合谁：手里有一堆自研或自托管应用要统一账号，希望自己握着用户目录，又不想为一台 JVM 和一整套中间件买单的团队；以及已经在用 Casbin 做权限、想顺势把认证也收进同一套体系的项目。
不适合谁：只需要在网关前加个登录页、用户数据本来就在别处且不打算迁移的场景，上完整 IdP 属于杀鸡用牛刀。另外它功能面铺得很宽（从 SAML 到人脸识别再到支付提供商），别指望一周内把所有能力都验证完。
真正花时间的地方不在装服务：一条 docker run 十分钟就能看到界面，难的是把存量应用的登录逻辑换掉、把散落各处的账号数据清洗合并、给离职与权限变更定流程。任何 SSO 项目都一样，工具只是把这部分工作变得可管理，不会替你做完。
最后提醒一句：上面那些演示站和默认凭据只用于评估。公网可见的实例如果还留着 built-in/admin/123，等于把身份中心的大门敞着。
本文整理自公开资料并做重写，原始出处：https://github.com/casdoor/casdoor。文中配图已去除站点叠加水印与推广信息；版权归原作者所有。