Casdoor を採用する前に確認したい、IdP 兼 MCP ゲートウェイという設計
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 はユーザーディレクトリそのものを自前で持ち、OAuth 2.0 から LDAP、SCIM、MCP までを 1 つのサーバーで話す Go 製の IdP だ。管理 UI で完結する構成と、その代わりに受け入れる運用コストを README の記述範囲で整理する。
- 誰に向いている？
- ユーザーディレクトリ自体を所有したいチーム、特に SPA と CAS しか話せないレガシーアプリを同じアカウント群で束ねたい場合や、MCP 経由のエージェントに既存の ID を渡したい場合には Casdoor は候補になる。逆に、既存リバースプロキシの手前にログイン画面を 1 枚足したいだけなら、より小さいツールのほうが適していると README 自身が書いている。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Casdoor が解決しようとしている問題は「認証プロキシ」ではなく「ディレクトリの所有」
多くの認証ミドルウェアは、既存のユーザーストアの前段に立つプロキシか、アプリに組み込むライブラリとして設計されている。Casdoor はそのどちらでもないと README は明言している。ユーザーを保存し、トークンを発行し、それを管理するコンソールまでを 1 つのサーバーとして提供する。アプリケーション側はログイン処理を完全に委譲し、パスワードを自分で扱わないという分担になる。
対象読者は、複数のプロトコルを話すアプリ群を同じアカウント群で運用したい組織だ。README は「モダンな SPA と CAS しか話せないレガシーアプリが 1 つのアカウント群を共有できる」という利点を挙げている。OAuth 2.0、OIDC、SAML 2.0、CAS、LDAP、SCIM 2.0、WebAuthn、TOTP/MFA、そして MCP が同じユーザーディレクトリ上で扱われる。逆に、リバースプロキシの手前にログイン画面を足すだけの用途は想定外で、README もその場合はより小さいツールを勧めている。
単一 Go バイナリとデータベースという構成、その上に Casbin の認可モデルが乗る
配布形態は Go の単一バイナリとデータベースという組み合わせで、JVM もオペレーターもクラスタも不要だと README は説明している。プロトコルごとに別コンポーネントを立てる構成ではないため、SAML 用と OIDC 用で別々のユーザーストアができるという事態は起きない。
認可は Casbin で表現される。ACL、RBAC、ABAC およびカスタムモデルに対応するとされ、固定の権限スキームを押し付けない。ここは設計上の分岐点になる。Casbin のモデル定義を書けるチームには柔軟だが、ロールとパーミッションが管理画面のチェックボックスで完結することを期待するチームには、モデルファイルという別の管理対象が増えることを意味する。README にはモデルの具体的な記述例までは示されていないため、実際にどの程度のカスタマイズが必要になるかはドキュメント側で確認する必要がある。
もう 1 つの特徴として、組織、アプリケーション、プロバイダ、サインイン方法、メールと SMS のテンプレート、ログインページのブランディングがすべて Web コンソールで編集できるとされている。設定ファイルを書き換えて再デプロイする運用から離れられる反面、設定の変更履歴やレビューを Git で追う運用とは相性が悪い。
30 秒で試す経路と、本番構成に進む経路は別物である
評価用の最短経路は all-in-one イメージだ。データベースも設定ファイルも不要で、SQLite とサンプルデータが同梱される。
docker run -p 8000:8000 casbin/casdoor-all-in-one
起動後 http://localhost:8000 を開き、組織に built-in、ユーザー名に admin、パスワードに 123 を入れる。README は、ドキュメント上で built-in/admin と書かれることがあるが、これはスラッシュを含むユーザー名ではなく組織とユーザー名の組だと注記している。ログインフォームでは組織とユーザー名が別フィールドになっているため、ここで混乱しやすい。
本番を見据えた経路は docker-compose.yml で、Casdoor と MySQL 8 のコンテナが並ぶ。ただし README は 2 点の注意を明示している。1 つ目は、Compose がソースからイメージをビルドする構成であり、Go バックエンドと React フロントエンドのビルドのため最初の docker compose up に数分かかること。2 つ目は、Casdoor を同梱データベースに向ける設定を先に行う必要があることだ。README の該当箇所は「Set the M」で切れているため、設定キーの正確な名前はここからは確認できない。docker-compose.yml 本体を読む必要がある。
ホストされたデモも 2 種類ある。demo.casdoor.com は書き込み可能だが約 5 分ごとに全データがリセットされる。door.casdoor.net は安定したグローバルデモで、すべての書き込み操作が設計上失敗する。どちらも同じ built-in / admin / 123 で入れる。挙動を確認したいのか、画面だけ見たいのかで使い分けることになる。
MCP とエージェント向けゲートウェイという位置づけは、既存 IdP との差分になる
リポジトリの説明とトピックには MCP、mcp-gateway、agent、agentic-ai、ai-gateway、openclaw が並び、README の対応プロトコル一覧にも MCP が含まれている。つまり Casdoor は、人間が使う SSO サーバーであると同時に、MCP 経由でツールに接続するエージェントに対して既存の ID を発行するゲートウェイとして提示されている。
この組み合わせが効くのは、エージェント用に別の認証基盤を立てたくない場合だ。ユーザーもエージェントも同じディレクトリ、同じ組織、同じ Casbin モデルの上に置ける。ただし、提供された資料には MCP の具体的なエンドポイントやトークン交換のフローまでは書かれていない。MCP 対応を採用理由にするなら、どの仕様に沿い、どのクライアントで検証されているかをドキュメントで確認してから決めるべきで、README の一覧に MCP の文字があることだけを根拠にするのは弱い。
ソースビルド前提の Compose と、消える all-in-one データ
最も現実的な落とし穴は、評価用の快適さがそのまま本番に持ち込めないことだ。all-in-one イメージはデータがコンテナ内にあり、コンテナと共に消えると README が明記している。本番用途を意図したものではない。
もう 1 つは Compose のビルド時間で、これは単なる待ち時間の問題ではない。イメージをソースからビルドする構成は、アップグレードのたびにビルド環境と依存関係の解決を自分で面倒を見ることを意味する。リリースは v4.1.0、v4.2.0、v4.3.0 と短期間に並んでおり、追従する頻度が高いならビルドパイプラインの整備は避けられない。
設定が UI 側にある点も、障害時の切り分けに影響する。設定ファイルがリポジトリにないため、環境の差分はデータベースの中身として存在する。バックアップと復元の対象がデータベースに集約されるのは利点だが、設定変更の差分レビューという手段は失われる。SCIM 2.0 に対応しているため、外部のディレクトリを正とする運用も選べる。どちらを正とするかを先に決めておかないと、ユーザーが二重管理になる。
Keycloak との違いは、拡張の場所がコードか UI かにある
比較対象として自然なのは Keycloak だ。どちらも OAuth 2.0、OIDC、SAML を話すセルフホスト型の IdP で、ユーザーフェデレーションを持つ。
差分は拡張の手段に出る。Keycloak は Java 製で、独自のロジックは SPI の実装として JVM 上に持ち込む。Casdoor は Go の単一バイナリで、README は JVM もオペレーターもクラスタも不要だと述べている。Java のビルドと配布に慣れた組織なら Keycloak の拡張モデルは資産になるが、Go のバイナリを 1 つ配る運用に寄せたいなら Casdoor のほうが素直だ。
認可の表現も違う。Casdoor は Casbin のモデルをそのまま使う。Keycloak 側はロールとパーミッションをコンソール上で組み立てる形が中心になる。ABAC のような属性ベースの判断をコードとして書きたいなら Casbin のモデル定義のほうが扱いやすく、管理画面の操作だけで完結させたいなら Keycloak のほうが向く。どちらが優れているという話ではなく、設定をコードとしてレビューしたいか、UI の操作として閉じたいかで選ぶことになる。
ライセンスとアップグレードの見積もり
ライセンスは Apache-2.0 で、リポジトリの LICENSE に準拠する。Apache-2.0 は商用利用や改変、再配布を許容する寛容型のライセンスだが、著作権表示とライセンス表示の保持、変更ファイルへの変更点の明示といった条件が付く。自前で改変したビルドを配布する場合は、この条件への対応を法務と確認する必要がある。ここでは法的助言はできない。
アップグレードコストはリリース間隔から推測できる。v4.1.0 から v4.3.0 までが 1 週間ほどの間隔で並んでいる。頻繁な追従を前提にするなら、Compose がソースビルドである以上、イメージビルドを CI に載せておくことが実質的な前提条件になる。設定がデータベース側にあるため、アップグレード手順にはスキーマ変更への対応が含まれる可能性がある。リリースノートでマイグレーションの要否を毎回確認する運用になる。
編集部の結論
ユーザーディレクトリ自体を所有したいチーム、特に SPA と CAS しか話せないレガシーアプリを同じアカウント群で束ねたい場合や、MCP 経由のエージェントに既存の ID を渡したい場合には Casdoor は候補になる。逆に、既存リバースプロキシの手前にログイン画面を 1 枚足したいだけなら、より小さいツールのほうが適していると README 自身が書いている。採用を決める前に確認すべきは、docker-compose.yml がソースからイメージをビルドする構成になっている点と、ALL-IN-ONE イメージのデータがコンテナと共に消える点だ。本番では MySQL 8 を別コンテナに置く前提の構成を自分で組み直す必要があり、その作業を省いたまま評価環境の感覚で本番に進めると、ユーザーデータの移行からやり直すことになる。
コミュニティノート