Keycloak 與 Authentik，企業級身分驗證的資源與功能對比
Authentik 由 Goauthentik.io 團隊於 2021 年前後推出，定位相當明確：以現代化的開發體驗與視覺化操作介面，解決傳統 IAM 方案「設定複雜、文件晦澀」的痛點。它以 Go 撰寫核心服務，搭配 Python 實作的流程引擎，整體架構採用容器化優先的設計，天然適合 Docker Compose 與 Kubernetes 部署。
Authentik 的一大特色是「流程（Flow）」與「階段（Stage）」的抽象模型。管理員可以透過視覺化介面組合登入流程，例如先做密碼驗證、再要求 TOTP、接著檢查裝置憑證、最後依群組決定是否允許進入。這種設計讓條件式存取與多步驟驗證的實作變得相當直觀，是它與 Keycloak 最大的體驗差異之一。此外，Authentik 提供「代理提供者（Proxy Provider）」與「RADIUS 提供者」，能保護不支援 OIDC/SAML 的舊系統，這在實務上非常實用。
需要留意的是，Authentik 採取「開源核心 + 企業版」的商業模式。核心功能以 MIT 授權釋出，但部分進階功能（例如部分企業級支援、特定稽核與治理能力）僅限企業版。企業在評估時應確認所需功能是否落在開源範圍內。
三、核心功能對比：認證協議、SSO 與使用者管理
以下從企業最關心的幾個功能面向，逐一比較兩者的能力與實作方式。
協定支援（OIDC / SAML / LDAP / OAuth 2.0）
在協議支援上，兩者都屬於「該有的都有」的等級，但細節略有不同。
整體而言，若企業環境中存在大量需要 Kerberos 整合的 Windows 生態，Keycloak 的覆蓋面略勝一籌；若企業的系統組合以現代 Web 應用為主，並希望用 Proxy 方式保護不支援 SSO 的內部工具，Authentik 的實用性更高。
使用者目錄與群組管理
Keycloak 以「Realm」作為租戶隔離單位，每個 Realm 擁有獨立的用戶、群組、角色與客戶端設定。這種多租戶設計適合集團企業區分不同事業單位，或是將內部員工與外部合作夥伴分置於不同 Realm。角色模型分為 Realm Role 與 Client Role，並支援複合角色（Composite Role）與細緻的授權策略。
Authentik 則以「Directory」為核心，提供使用者、群組與角色的管理，並可透過 Expression Policy 以程式化方式定義動態群組與存取條件。它的群組與權限設計較為扁平直覺，對於中小型團隊上手更快；但在超大型組織的階層式權限模型中，Keycloak 的角色體系仍較成熟。
多因素驗證（MFA）與無密碼登入
兩者都支援 TOTP、WebAuthn/Passkey 與備援碼。Keycloak 的 MFA 設定需在 Authentication Flow 中組合，靈活但需要理解其流程模型；Authentik 則將 MFA 包裝成易於組合的 Stage，管理員可在視覺化介面中快速建立「密碼 + TOTP + 裝置驗證」的登入流程。
在無密碼（Passwordless）趨勢上，兩者都已支援 WebAuthn。Authentik 在近期版本中對 Passkey 的支援與介面引導做得較為友善；Keycloak 則需要較多手動設定，但可透過條件式流程實現更複雜的政策，例如「內部網路免 MFA、外部網路強制 MFA」。
四、部署架構、資源消耗與擴充性
對於自架 IAM，硬體資源與維運複雜度往往比功能列表更具決定性。這也是 Keycloak 與 Authentik 差異最明顯的地方。
硬體與記憶體資源實測比較
Keycloak 是 JVM 應用，即便 Quarkus 版本已大幅優化，在中小型部署中仍建議配置至少 2 至 4 GB 記憶體，方能維持穩定的回應速度；若啟用快取、叢集與大量身分聯邦，記憶體需求會進一步上升。啟動時間在容器環境中通常需要數十秒。
Authentik 的 Server 以 Go 撰寫，記憶體足跡明顯較小，在一般負載下數百 MB 即可運作；但其架構包含 Server、Worker 與資料庫（PostgreSQL）與 Redis，整體仍需一組完整的容器堆疊。換言之，Authentik 單一容器的資源效率較佳，但服務元件數量較多，維運時需要關注的元件也相對增加。
比較項目
Keycloak
Authentik
語言與執行環境
Java（Quarkus）
Go（核心）＋ Python（流程引擎）
建議記憶體
2～4 GB 起
512 MB～2 GB 起
資料庫
PostgreSQL、MySQL、MariaDB、Oracle、MSSQL
PostgreSQL（主要）
快取／佇列
Infinispan（內建叢集快取）
Redis
高可用部署
成熟，支援叢集與跨資料中心
支援多副本，需外部資料庫與 Redis
叢集、高可用性與資料庫支援
Keycloak 在高可用性上的成熟度較高，它內建 Infinispan 分散式快取，官方文件對叢集部署、負載平衡、跨資料中心複寫有完整說明，並有大量企業實作經驗可供參考。資料庫選擇也相當多元，對既有使用 Oracle 或 SQL Server 的企業較為友善。
Authentik 的高可用部署主要依賴「多副本 + 外部 PostgreSQL + Redis」的標準雲原生模式，在 Kubernetes 環境中相對直覺，透過 Deployment 擴展副本即可。不過其官方對超大規模叢集的案例與調校指引，仍不如 Keycloak 豐富。
五、開發者體驗與整合生態
IAM 方案是否好用，很大程度取決於開發團隊的整合體驗。這部分兩者各有擅場。
API、SDK 與文件品質
Keycloak 提供完整的 Admin REST API，社群也發展出各語言的管理 SDK（Java、Python、Go、Node.js 等）。官方文件詳盡，但結構偏向「參考手冊」，新手需要花時間摸索。其帳號主控台與管理介面的可客製化程度高，可透過主題（Theme）機制替換登入頁面樣式。
Authentik 同樣提供 REST API，並以 OpenAPI 規格自動產生文件，開發者可直接在介面中測試端點。它的官方文件以「任務導向」撰寫，搭配截圖，上手速度較快。整體開發者體驗較現代，但在第三方 SDK 的廣度上仍不及 Keycloak 的十年累積。
與 Kubernetes、雲端服務及第三方應用的整合
兩者都提供官方 Helm Chart 與容器映像，可部署於 Kubernetes。Keycloak 有 Operator（Keycloak Operator）可管理 Realm 與 Client 的宣告式設定，適合 GitOps 流程；Authentik 則以 Kubernetes 的 Ingress 註解與 Proxy Provider 方式，將未支援 OIDC 的服務納入保護，這在實務上非常方便。
在第三方整合方面，Keycloak 由於歷史悠久，幾乎所有主流開源軟體（GitLab、Jenkins、Grafana、Nextcloud、Superset 等）的文件中都能找到 Keycloak 的設定範例。Authentik 的整合清單近年快速擴充，已涵蓋大量常見應用，並以「Integration 精靈」降低設定門檻。
六、企業治理、法規遵循與安全性
企業級 IAM 的價值不只在「能不能登入」，更在「能不能證明誰在什麼時間、從哪裡、以何種方式登入」。這牽涉稽核與治理能力。
稽核日誌、RBAC 與政策控管
Keycloak 內建事件記錄（Event Listener），可將登入、登出、管理操作等事件輸出至檔案、資料庫或外部系統，並可透過 SPI 擴充自訂監聽器。RBAC 模型完整，授權服務（Authorization Services）支援以資源為基礎的細緻政策（例如 UMA 2.0）。對於需要符合嚴格稽核要求的金融或政府單位，這種可追溯性是重要優勢。
Authentik 提供事件日誌與稽核介面，能記錄登入與管理事件，並可搭配政策引擎實現條件式存取。其「Flow」模型讓政策實作更直觀，但在稽核輸出的格式彈性與外部 SIEM 整合深度上，目前仍以企業版功能較為完整，開源版需自行評估是否足夠。
漏洞應變與社群回應速度
Keycloak 背後有 Red Hat 的安全團隊，CVE 處理流程相對制度化，重大漏洞通常會有明確的修補版本與公告。社群規模龐大，問題在 Stack Overflow 與 GitHub 上較容易找到解答。
Authentik 的開發團隊活躍，GitHub Issues 與 Discord 社群回應速度快，版本迭代頻繁，新功能推出節奏快。但相對地，頻繁的版本更新也意味著企業需要投入較多心力進行升級測試與回歸驗證。
七、授權模式、營運成本與總體擁有成本（TCO）
選型時若只看「軟體免費」，很容易低估長期成本。真正的 TCO 應包含授權、硬體、人力與升級維護。
開源授權差異
Keycloak 採用 Apache License 2.0，對商業使用友善，無須擔心衍生作品授權問題。Authentik 的核心採用 MIT 授權，同樣寬鬆，但需注意其企業版功能（Enterprise Edition）需付費訂閱。若企業需要的功能恰好落在企業版範疇，則應將訂閱費納入比較。
維運人力與學習曲線
Keycloak 的學習曲線較陡，管理員需要理解 Realm、Client、Authentication Flow、User Federation、SPI 等概念。但一旦熟悉，其功能深度與社群資源能支撐長期演進。若企業已有 Java 維運能力，導入成本會顯著降低。
Authentik 的介面直觀，中小型團隊可在數小時內完成基本部署與第一個應用整合，前期導入速度快。但當架構複雜化（多租戶、複雜政策、高可用）時，仍需具備容器與 PostgreSQL、Redis 的維運能力。整體而言，Authentik 的「初期時間成本」較低，Keycloak 的「長期功能天花板」較高。
八、選型建議：什麼情況該選 Keycloak？什麼情況該選 Authentik？
沒有一個方案能適用所有情境。以下依據常見的企業樣態提供判斷方向。
適合 Keycloak 的企業情境
組織規模較大，需要多 Realm 租戶隔離與複雜的角色權限模型。
既有環境以 Java 生態為主，或已使用 Red Hat 產品線。
需要與 Active Directory、Kerberos 深度整合，實現桌面單一登入。
對稽核、法規遵循與漏洞修補流程有嚴格要求，需要成熟的商業支援選項。
系統整合清單龐雜，期望能直接沿用既有社群設定範例。
適合 Authentik 的企業情境
團隊規模中小，希望快速完成部署並在短時間內整合數十個應用。
基礎架構以 Kubernetes 與容器為主，偏好雲原生部署模式。
需要以 Proxy 或 RADIUS 方式保護不支援 OIDC/SAML 的舊系統。
重視現代化介面與視覺化流程設計，減少手動設定錯誤。
願意跟隨較頻繁的版本節奏，並具備容器維運能力。
九、結論與實務建議
總結來說，Keycloak 與 Authentik 都是成熟的開源企業級 IAM 方案，差別在於「深度」與「易用性」的取捨。Keycloak 像是一套功能齊全的企業級工具機，功能深度、叢集成熟度、治理能力與生態廣度都經過十年以上的驗證，適合大型組織與複雜的合規環境；Authentik 則像是一套設計精良的現代化控制台，以視覺化流程、輕量架構與雲原生部署降低導入門檻，特別適合中小型團隊或快速成長的新創。
在實務上，建議企業採取「先做概念驗證（PoC）」的策略：以真實的三到五個應用（包含一個現代 OIDC 應用、一個 SAML 應用、一個僅支援 LDAP 的舊系統）進行整合測試，同時量測登入延遲、資源消耗與管理操作效率。此外，務必將「升級與備援」納入驗收標準——IAM 是所有系統的入口，一旦故障，影響面遠大於單一應用。無論選擇哪一套，都應規劃資料庫備份、金鑰管理（Key Rotation）、憑證更新與災難復原流程。
最後提醒，身分驗證服務是企業資安的「單點」，也是「單點風險」。選擇社群活躍、修補迅速、且團隊真正有能力維運的方案，遠比追逐功能列表上的勾選項目更為重要。Keycloak 與 Authentik 都值得納入候選名單，關鍵在於企業自身的規模、技術棧與治理需求，而非誰的功能「比較多」。
```
💬 想說點什麼？
歡迎到留言板分享你的想法、心得或疑問。
💬 前往留言板 →