Casdoor: A Self-Hosted IAM That Speaks MCP Alongside OAuth and SAML

What Casdoor Actually Solves

Casdoor is a complete identity provider, not an authentication proxy or an embeddable library. The README is explicit: it stores your users, issues the tokens, and gives you an admin console to manage everything. Applications delegate login entirely and never handle passwords themselves. This matters for teams that have multiple applications, including legacy CAS-only systems and modern SPAs, that need to share one set of accounts. The project's pitch is that one server can speak OAuth 2.0, OIDC, SAML 2.0, CAS, LDAP, and SCIM against the same user directory. The recent addition of MCP (Model Context Protocol) support extends that reach to AI agents, which is what the 'agent-first' label in the repository description refers to. The intended user is an organization that wants to own its identity layer and is willing to run a Go binary plus a database, rather than rely on a hosted service.

The Architecture: One Directory, Many Protocols, UI-Driven Config

Casdoor's core design is a single user directory that is exposed over multiple protocols. The README describes it as 'one server, many protocols.' The same set of accounts can be reached by an OAuth 2.0 SPA, a SAML 2.0 enterprise app, and a CAS-only legacy tool. That is not a trivial feature; most IAM products pick one or two protocols and force you to sync directories. Casdoor instead makes the protocol adapters layers over the same underlying user store. The second architectural pillar is that configuration is done in the web console, not in files that require redeployment. Organizations, applications, providers, sign-in methods, email templates, and login-page branding are all editable in the UI. The README shows an application settings page where you can toggle OAuth, SAML, providers, and branding without touching a config file. Third, authorization is policy-based via Casbin, supporting ACL, RBAC, ABAC, and custom models. That means access rules are not hard-coded into Casdoor; you define them with Casbin's model language. The web UI screenshots confirm that the admin console gives you a dashboard for users, tokens, organizations, and providers, plus a list of all applications that delegate login.

Getting It Running: Four Paths, One Quick Demo

The README lists four installation paths, and the fastest is a single Docker command that requires no database and no config file. Running `docker run -p 8000:8000 casbin/casdoor-all-in-one` starts Casdoor on SQLite with sample data. You then open http://localhost:8000 and sign in with organization `built-in`, username `admin`, and password `123`. That image is explicitly for evaluation: the data lives inside the container and disappears with it. For a more realistic setup, the repository includes a `docker-compose.yml` that starts Casdoor next to a MySQL 8 container. There are two caveats in the README: the Compose file builds the image from source (Go backend plus React frontend), so the first `docker compose up` takes several minutes; and you must first point Casdoor at the bundled database. The README is truncated at that point, so the exact environment variable or config key for the database connection is not visible in the material I have. The other two paths are not detailed in the provided text, but the existence of a Go binary and a database is confirmed by the 'Straightforward to self-host' statement: no JVM, no operator, no cluster.

The Agent and MCP Angle: Where the Project Is Heading

The repository description calls Casdoor an 'Agent-first Identity and Access Management (IAM) / LLM MCP & agent gateway and auth server.' The README itself does not elaborate on MCP beyond listing it among the protocols Casdoor speaks. The release cadence is fast: v4.1.0 on 2026-09-02, v4.2.0 on 2026-09-06, and v4.3.0 on 2026-09-09, roughly a week apart. That suggests active development around the agent gateway features. But the documentation gap is real. If you are evaluating Casdoor specifically for MCP or OpenClaw integration, the README gives you almost nothing to go on. You would need to consult the docs at casdoor.ai or the release notes to understand how the MCP gateway is configured, what an 'agent gateway' means in practice, and how it handles authentication for LLM tools. That is a limitation for a project that puts 'agent-first' in its first sentence. The core IAM features are well documented in the README, but the new agent-facing capabilities appear to be evolving faster than the documentation can keep up.

A Genuine Limitation: The All-in-One Image Is Not Production-Ready

The most concrete limitation in the README is the warning about the all-in-one Docker image: it is 'not intended for production' because the data lives inside the container and disappears with it. That is a clear failure mode for anyone who mistakes the quick demo for a deployable system. The Compose path with MySQL is more production-like, but it builds from source, which means a slow first startup and a dependency on your build environment. Another limitation is that Casdoor is not the right tool if all you need is a login screen in front of an existing reverse proxy. The README says as much: 'a smaller tool may suit you better.' Casdoor's value is owning the user directory itself, which is a heavier commitment. Finally, the separate organization and username fields on the sign-in form can confuse users who expect a single username field. The README notes that docs sometimes write the pair as `built-in/admin`, but that is not a username containing a slash. That is a minor UX quirk, but it points to a design that assumes users understand the concept of organizations.

Alternatives: How Casdoor Differs from Lighter Tools

The README itself names the primary alternative category: 'a smaller tool' for login in front of a reverse proxy. Examples would be oauth2-proxy or Authelia, which act as authentication proxies and do not store a full user directory. Those tools are typically configured via YAML files and are designed to protect a single ingress or a small set of services. Casdoor, by contrast, is a full identity provider with its own user storage, admin console, and multi-protocol support. The difference in approach is fundamental: a proxy forwards authentication to an upstream IdP, while Casdoor is the IdP. If you already have an identity provider like Keycloak, Casdoor is a competing alternative. Keycloak is also a self-hosted IdP with a UI, but it runs on Java and requires a JVM, whereas Casdoor is a single Go binary. The README emphasizes that as a selling point: 'No JVM, no operator, no cluster required.' So the real choice is between a lightweight proxy (if you don't need a user directory) and a heavier IdP like Keycloak (if you do). Casdoor sits in the middle: it is heavier than a proxy but lighter than a Java-based IdP.

Maintenance and Upgrade Cost

Casdoor is licensed under Apache-2.0, which is permissive and imposes few restrictions on use, modification, or redistribution. That is a positive for adoption. The maintenance cost is tied to the release cadence: three minor versions in a week suggests a project in rapid development, which means you should expect frequent updates and potential breaking changes. The README does not describe a migration path between versions, and the material I have does not mention database schema versioning or upgrade tooling. That is a gap. If you deploy Casdoor with MySQL, you will need to plan for regular upgrades and test them against your configuration. The fact that configuration is UI-driven reduces the cost of changing settings, but it also means that infrastructure-as-code teams cannot easily version their IAM configuration in Git. The README does not mention any export or import mechanism for configuration, so reproducing an environment might require manual UI steps. That is a real operational cost to weigh against the convenience of the console.

Editorial conclusion

Adopt Casdoor if you want to own a full user directory and expose it across many protocols, especially if you are experimenting with MCP or agent gateways and prefer a UI over config files. Do not adopt it if you only need a login proxy in front of an existing reverse proxy, or if you require a production database with minimal setup: the all-in-one Docker image is explicitly not for production, and the Compose path builds from source and takes minutes. Before committing, verify that the database you plan to use (MySQL 8 or another supported backend) is covered in the documentation, and check the current release notes for v4.3.0 to confirm which MCP and agent features are stable in your deployment.

Official sources

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