Casdoor: Self-Hosted Identity Management with SSO, SAML, LDAP, and MCP

What Casdoor Is and Who It Is For

Casdoor is a complete identity provider, not an authentication proxy and not an embedded library. The README draws this distinction explicitly: it stores your users, issues the tokens, and gives you an admin console to manage all of it, so your applications can delegate login entirely and never handle a password themselves. That design suits teams building multiple internal applications that need shared authentication, or organizations replacing a patchwork of per-app login systems with a central one. The web console lets you configure organizations, applications, identity providers, sign-in methods, email and SMS templates, and login-page branding without redeploying or editing files. Casdoor is backed by Casbin for access control, which means authorization rules can be expressed as ACL, RBAC, ABAC, or custom models rather than a fixed permission scheme.

Protocol Breadth and the MCP Gateway

A single Casdoor deployment serves OAuth 2.0, OIDC, SAML 2.0, CAS, LDAP, SCIM 2.0, WebAuthn, TOTP/MFA, and MCP from the same user store. The README frames this as solving a concrete problem: a modern SPA and a legacy CAS-only application can share one set of accounts because the same user directory is reachable over multiple protocols simultaneously. Casdoor also connects to external identity providers, including Google Workspace, Microsoft Entra ID (Azure AD), and GitHub, acting as a hub that federates external logins into the central directory. The MCP support positions it as an agent gateway for AI workflows, though the repository description names it an "Agent-first" IAM server. The go.mod file lists dependencies for payment providers (Paddle, Adyen, LemonSqueezy), face ID, Coraza web application firewall, and a Radius protocol implementation, indicating that the protocol surface extends well beyond the core SSO use case.

Getting Casdoor Running: Docker and Helm

The fastest path is the all-in-one Docker image, which bundles SQLite and demo data into a single container:

docker run -p 8000:8000 casbin/casdoor-all-in-one

Open http://localhost:8000 and sign in with organization `built-in`, username `admin`, password `123`. The sign-in form has separate organization and username fields; the README notes that documentation sometimes writes this as `built-in/admin`, which is not a slash-separated username but the organization and username pair. The README is direct that this image is not intended for production: data lives inside the container and disappears when it is removed. For a production-style local setup with MySQL, edit conf/app.conf to set the driver and connection:

driverName = mysql
dataSourceName = root:123456@tcp(localhost:3306)/
dbName = casdoor

Then start with Docker Compose:

docker compose up

The Compose file sets RUNNING_IN_DOCKER=true, and Casdoor rewrites localhost to the Docker host address at startup. The Compose entrypoint passes --createDatabase=true so the casdoor database is created automatically. The first docker compose up builds from source (Go backend and React frontend), which takes several minutes. For Kubernetes, the Helm chart is:

helm install casdoor oci://registry-1.docker.io/casbin/casdoor-helm-charts

The chart does not expose Casdoor outside the cluster by default.

Architecture: One Go Binary with a React Frontend

Casdoor ships as a single Go binary. The Dockerfile confirms the build process: the React frontend is compiled with yarn build in a Node 20 container, the Go backend is compiled with a build.sh script in a Go 1.25.8 container, and the final Alpine image contains the server binary, the swagger directory, app.conf, and the compiled web build. There is no JVM, no operator, and no cluster required for a basic deployment. The go.mod declares module github.com/casdoor/casdoor and requires Go 1.25.0. The repository layout shows separate top-level directories for controllers/, routers/, object/, service/, idp/ (identity providers), ldap/, scim/, mcp/, and web/, which reflects the protocol breadth. The mcp/ and mcpself/ directories indicate that MCP support is implemented as a first-class module, not a plugin.

Casdoor vs. Keycloak and Smaller Alternatives

Casdoor and Keycloak address a similar use case: self-hosted SSO with multiple protocol support. The practical difference is deployment weight. Keycloak requires a JVM and is typically run with its own cluster tooling or operator in Kubernetes. Casdoor is a single Go binary with a database, which reduces the operational surface for teams that do not already run JVM workloads. The README notes that if all you need is a login screen in front of an existing reverse proxy, a smaller tool may suit you better, which is an honest acknowledgment that Casdoor's user-directory ownership model is overhead if you only need a proxy. Against Logto, which also targets developer-friendly SSO, the key difference is that Casdoor adds LDAP, SCIM, and CAS support alongside OIDC, making it usable in enterprise environments with legacy protocol requirements.

Real Limitations and Failure Modes

The all-in-one Docker image loses all data when the container stops, which catches teams that use it beyond evaluation. The Compose setup builds from source on the first run, taking several minutes and requiring a build environment, not just a container runtime. The Helm chart requires manual ingress configuration to expose Casdoor outside a Kubernetes cluster. Casdoor stores user passwords itself rather than delegating to an external store by default, which means the security of the credential database is your responsibility. The repository includes a SECURITY.md but the README does not describe a process for credential rotation, account lockout policy, or audit-log access, so you will need to verify those capabilities in the documentation before committing to a production deployment. The SQLite path in the all-in-one image is described as evaluation-only with no migration path from SQLite to MySQL documented in the README.

Licensing and Maintenance

Casdoor is licensed under Apache-2.0, which permits commercial use, modification, distribution, and private use without requiring derivative works to be open sourced. The last repository push was on 2026-09-27, and three releases (v4.9.0 through v4.11.0) were published in the five days before that push, indicating a fast release cadence. The go.mod uses Go 1.25.0 as the minimum and Go 1.25.8 as the toolchain, which reflects a current Go version. The repository includes integration with multiple payment providers and cloud storage backends, which suggests ongoing feature expansion. Casdoor is maintained by the same team behind the Casbin authorization library; the two projects share a package namespace under github.com/casbin.

Editorial conclusion

Teams that need a self-hosted user directory with support for both modern protocols (OIDC, MCP) and legacy ones (SAML 2.0, CAS, LDAP) in a single deployable binary will find Casdoor a direct fit. It is the wrong choice when all you need is a login proxy in front of an existing reverse proxy without managing users, or when your organization requires a FIPS-certified or government-evaluated identity product. Before deploying to production, verify whether the all-in-one Docker image (which uses SQLite and loses data when the container is removed) is acceptable, and switch to the MySQL or PostgreSQL path via conf/app.conf for any environment where data must persist.

Frequently asked questions

Official sources

1. casdoor/casdoor on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases