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. 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. The README's first caveat is that Compose builds the image from source (Go backend plus React frontend), so the first `docker compose up` takes several minutes. The README's self-hosting summary is a single Go binary plus a database: 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's opening lists MCP among the protocols Casdoor speaks, and the repository has top-level `mcp/` and `mcpself/` directories. The release cadence is fast: v4.23.0 on 2026-10-21, v4.24.0 on 2026-10-25, and v4.25.0 on 2026-10-30, four to five days apart. That suggests active development. If you are evaluating Casdoor specifically for MCP or OpenClaw integration, 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.

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. 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 nine days suggests a project in rapid development, which means you should expect frequent updates and potential breaking changes. If you deploy Casdoor with MySQL, you will need to plan for regular upgrades and test them against your configuration. UI-driven configuration reduces the cost of changing settings; infrastructure-as-code teams should check the full documentation for how configuration can be reproduced across environments.

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.25.0 to confirm which MCP and agent features are stable in your deployment.

Frequently asked questions

Official sources

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