Casdoor：把 MCP 閘道塞進既有 IAM 的 Go 開源方案
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 是一個以 Go 寫成、可自架的單一登入與授權伺服器，近期版本把 MCP 與 agent 閘道納入同一套身份目錄。本文檢視它的架構、部署路徑、以及它與純認證代理工具之間的界線。
- 適合誰用？
- Casdoor 適合想要自己掌握使用者目錄、又需要同時服務現代 SPA 與舊 CAS 應用的團隊，尤其是那些已經在評估 MCP 或 agent 閘道、希望把身份與閘道放在同一個管理介面的人。若你只需要在反向代理前面加一層登入畫面，Casdoor 是過度設計，更輕量的工具才對。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的不是登入，而是身份目錄的歸屬
Casdoor 把自己定位成完整的身份提供者，而不是認證代理或可嵌入的函式庫。這個區分很關鍵。代理只擋在資源前面，不儲存使用者；函式庫讓你的應用自己管密碼。Casdoor 兩者都不做，它自己存放使用者、發行 token、提供管理後台。README 明說：如果你的需求只是在既有反向代理前加一個登入畫面，更小的工具可能更適合。它的目標對象是想要擁有使用者目錄本身的團隊。這意味著你一旦採用，使用者的增刪改查、密碼重設、多因素驗證都集中在這台伺服器，而不是散落在各應用。對於同時有現代 SPA 和舊 CAS 應用的組織，這種集中目錄的價值在於一套帳號可以透過多種協議被存取。
從 OAuth 到 MCP：同一目錄，多種協議
Casdoor 的核心機制是讓同一個使用者目錄同時對外提供 OAuth 2.0、OIDC、SAML 2.0、CAS、LDAP 和 SCIM。這不是多個獨立模組，而是同一批使用者紀錄透過不同協議轉譯。管理員在後台設定應用程式，每個應用可以啟用不同的協議與身份提供者。README 特別提到 v4.3.0 加入了 MCP 與 agent 閘道功能，讓 Casdoor 不只是認證伺服器，還能作為 LLM 與 MCP 的閘道。這代表 Casdoor 正從傳統 IAM 擴張到 agentic AI 的基礎設施。但要注意，這種擴張是漸進的，v4.3.0 在 2026 年 9 月 9 日才發布，距離現在不過數日，功能成熟度有待驗證。README 對 MCP 閘道的技術細節著墨不多，只把它列為支援的協議之一。
授權策略交給 Casbin，而不是寫死在程式裡
Casdoor 內建政策式授權，用的是 Casbin 專案。這表示存取規則可以用 ACL、RBAC、ABAC 或自訂模型來表達，而不是綁死在一種固定權限方案。這對需要細緻授權的企業是優點，因為你可以在不改程式碼的情況下調整權限模型。但這也帶來學習成本：Casbin 的 policy 語法與模型定義是另一套知識，團隊若從未接觸過，需要額外時間熟悉。README 沒有提供具體的 Casbin 設定範例，只說它內建。實際使用時，你必須查 Casbin 文件才能寫出第一個 policy。這是一個潛在的入門障礙，尤其是對只想快速架 SSO 的小團隊。
三十秒啟動的 Docker 映像，與它背後的生產陷阱
README 提供一個號稱免資料庫、免設定檔的快速啟動方式：執行 docker run -p 8000:8000 casbin/casdoor-all-in-one，然後用 built-in 組織、admin 使用者、密碼 123 登入。這個映像把 SQLite 和示範資料打包在單一容器，適合第一次試看。但 README 自己警告：不適合生產，因為資料存在容器內，容器消失資料就跟著消失。這是典型的評估用捷徑，容易讓人誤以為正式部署也這麼簡單。實際的 Docker Compose 路徑就完全不同：docker-compose.yml 會啟動 Casdoor 搭配 MySQL 8，而且 Compose 是從原始碼建構映像，包含 Go 後端與 React 前端，第一次 docker compose up 需要好幾分鐘。此外，你必須先設定 Casdoor 指向隨附的資料庫，README 這段被截斷，但顯然不是開箱即用。
管理後台：所有設定都在 UI，但升級時要付出代價
Casdoor 的管理後台讓你在網頁上設定組織、應用程式、身份提供者、登入方式、電子郵件與 SMS 範本，以及登入頁面的品牌。README 強調不需要重新部署或改設定檔。這種設計對日常維運很友善，非工程師也能調整登入頁的外觀。但它有個隱藏成本：當所有狀態都存在資料庫，升級 Casdoor 版本時，你必須依賴官方遷移腳本把舊設定轉到新結構。v4.1.0 到 v4.3.0 之間只隔了七天，發布節奏很快，代表遷移路徑可能還不穩定。如果你重度依賴 UI 客製化，每次升級都要重新驗證那些設定是否仍然有效。這是用 UI 彈性換來的維運負擔，README 沒有提到這點，但從發布頻率可以合理推斷。
真正的替代方案：輕量認證代理 vs 完整 IdP
Casdoor 的主要替代品不是另一個 IdP，而是認證代理，例如 oauth2-proxy 或 Authelia 這類工具。差別在於：代理不儲存使用者，它把認證轉給上游 IdP，自己只負責保護路由。如果你的需求是讓內部工具有一個登入畫面，而且你已經有 Google Workspace 或 Azure AD 當身份來源，代理會更輕、更少維護。Casdoor 則是要你接管整個目錄，包括使用者生命週期、密碼原則、MFA 註冊。另一個替代是直接用雲端 IdP，例如 Entra ID 或 Okta，但那就不是自架。Casdoor 的文件與程式碼都是開放原始碼，Apache-2.0 授權，你可以修改後商用，但雲端服務你只能接受它的條款。選擇的關鍵在於你是否願意承擔使用者目錄的營運責任。
授權與維護成本：Apache-2.0 的彈性與升級節奏
Casdoor 採用 Apache-2.0 授權，這對商用是友善的，你可以修改、分發、甚至把它嵌入付費產品，只要保留著作權聲明。沒有 copyleft 的包袱，不像 AGPL 那樣要求網路服務開放原始碼。維護成本方面，專案使用 Go 寫成，部署是單一二進位檔加資料庫，不需要 JVM 或 Kubernetes operator，這降低了基礎設施複雜度。但發布頻率很快，v4.1.0 到 v4.3.0 在一個星期內連續釋出，代表你必須頻繁追蹤更新以取得安全修正。每次升級都需要測試既有設定，尤其是如果你用了 UI 上的進階功能。README 沒有提供長期支援版本的承諾，所以你等於跟著 master 分支的節奏走。
編輯結論
Casdoor 適合想要自己掌握使用者目錄、又需要同時服務現代 SPA 與舊 CAS 應用的團隊，尤其是那些已經在評估 MCP 或 agent 閘道、希望把身份與閘道放在同一個管理介面的人。若你只需要在反向代理前面加一層登入畫面，Casdoor 是過度設計，更輕量的工具才對。採用前應先確認兩件事：其一，你能否接受 SQLite 容器內資料隨容器消失的限制，正式環境必須改用 MySQL 或 PostgreSQL，並確認 docker-compose.yml 中指向資料庫的設定；其二，MCP 閘道功能在 v4.3.0 才剛發布，你需要實際測試它與你現有 agent 框架的相容性，而不是假設它與專屬閘道產品等價。授權為 Apache-2.0，商用或修改皆無障礙，但升級時要留意版本間協議設定的遷移，因為 UI 可改的設定越多，升級腳本要處理的狀態就越多。
社群筆記