雅寶社區 · 頂客論壇 (AHPAL.COM)

📊 軟體評測

Authentik 與 Authelia，自架 SSO 的設定難度與整合度

發表時間：2026 年 11 月 14 日 | 更新日期：2026 年 11 月 14 日 | 編輯：雅寶社區編輯團隊

2-1 架構與部署方式

Authentik 的標準部署架構包含四個核心元件：server（處理 Web 與 API 請求）、worker（處理背景任務，例如寄信、同步、稽核寫入）、PostgreSQL（主要資料庫）以及 Redis（快取與任務佇列）。官方提供完整的 Docker Compose 範例，也有 Helm Chart 可部署到 Kubernetes。這代表你在啟動之前，就必須先準備好資料庫與快取這兩個外部依賴。

對於家庭實驗室玩家來說，這其實不算太困難，因為多數人本來就已經有 PostgreSQL 與 Redis 的容器在跑。但如果你是完全從零開始，就要理解「為什麼一個登入系統需要 Redis」這類問題。官方文件對這個架構的說明算清楚，Docker Compose 範例也幾乎可以照抄，只要把環境變數裡的密鑰與主機名稱改掉，通常十到二十分鐘內就能把服務跑起來。

比較需要注意的反而是資源需求。含 PostgreSQL 與 Redis 在內，一個基礎的 Authentik 部署建議至少準備 2GB 記憶體，若要跑得順暢、加上 worker 的背景任務，4GB 會是比較舒服的配置。這對小型 VPS 或低功耗迷你主機來說，是一個需要納入考量的門檻。

2-2 設定流程與實際操作體驗

Authentik 最為人稱道的一點，就是它有完整的圖形化管理介面。初始啟動後，你會透過精靈建立管理員帳號，接著所有設定——使用者、群組、應用程式、供應商（Provider）、流程（Flow）、政策（Policy）、Outpost——幾乎都能在 Web UI 中完成，不需要手改設定檔。這對不喜歡編輯 YAML 的人來說是一大福音。

但也是從這裡開始，學習曲線開始變陡。Authentik 的核心概念是「流程引擎」：每一個登入、註冊、重設密碼的動作，背後都是一連串的「階段」（Stage）所組成。這個設計非常強大，讓你可以在登入流程中插入自訂的提示、檢查、甚至條件式政策；但對於只想「讓 Nextcloud 可以用 SSO 登入」的人來說，首次看到 Flow、Stage、Binding、Policy 這些名詞時，很容易感到一頭霧水。

舉例來說，要讓一個應用程式走 OIDC 登入，你需要：建立一個 OAuth2/OIDC Provider、建立一個 Application 並綁定該 Provider、確認使用者的群組有被授權、再確認該 Application 有被納入對應的 Outpost 或政策。這四個步驟在 UI 上都不難點，但如果順序錯了或授權沒設好，就會出現「登入成功但被拒絕存取」的狀況，除錯時需要對整個模型有基本理解。

另一方面，如果你要的是 forward-auth（把應用程式放在反向代理後面，由 Authentik 負責驗證），則需要另外部署 Outpost。Outpost 是 Authentik 架構中相對獨立的一塊，它可以是內嵌模式，也可以是獨立容器。獨立容器模式彈性高，但多了一個要維護的元件，網路連線與憑證設定也要特別留意。整體而言，Authentik 的「首次上手」比想像中容易，「深度客製」則比想像中複雜。

2-3 整合能力與生態系

整合度是 Authentik 最大的優勢。它原生支援 OAuth 2.0 / OIDC、SAML 2.0，也能作為 LDAP Provider 讓不支援現代協定的老應用程式透過 LDAP 綁定驗證。它內建多因素驗證，支援 TOTP、WebAuthn、Duo 等機制，並且可以在流程中強制啟用。它也有 SCIM 相關的目錄同步能力（部分功能屬於商業版），以及對多租戶品牌設定的支援，讓不同網域可以有不同的登入外觀。

在應用程式支援方面，Authentik 官方文件與社群累積了大量教學，從 Grafana、Nextcloud、Proxmox、Portainer、Mattermost、Jellyfin 到各種主流開源服務，幾乎都找得到對應的設定範例。這對於自架玩家來說非常重要，因為「有沒有人寫過教學」往往比「功能是否支援」更能決定你會不會卡關。

此外，Authentik 的 Outpost 可以部署在與主服務不同的網路環境，對於有 DMZ 或跨網段需求的進階使用者來說，這種分散式架構提供了相當大的彈性。整體來說，Authentik 的整合度屬於「上限很高」的類型：你願意花時間學，它幾乎什麼都做得到；但如果你只想用最簡單的方式，反而會覺得它有點殺雞用牛刀。

三、Authelia 深度評測：輕量級反向代理守門員

Authelia 是一套以 Go 語言撰寫的開源專案，主打輕量、快速、設定導向。它沒有資料庫就幾乎可以運作（使用檔案式使用者與記憶體 session），也不需要獨立的 worker 或 outpost。它的核心價值非常明確：站在反向代理前面，替你的服務加上一道登入與 2FA 的關卡，並且提供 OIDC Provider 功能讓支援的應用程式直接串接。

3-1 架構與部署方式

Authelia 的部署極其單純：它就是一個容器（或一個執行檔），加上一份 YAML 設定檔。使用者來源可以是本機檔案（users_database.yml）、LDAP / Active Directory，或是記憶體中的測試使用者。Session 預設存在記憶體，若要支援多實例或重啟後保留登入狀態，才需要加上 Redis。若你要使用 OIDC Provider 功能，則需要一個儲存後端，可以是本機 SQLite 或 PostgreSQL。

這意味著最小可行的 Authelia 部署，只需要一個容器加上一份設定檔，記憶體佔用通常在一兩百 MB 上下，對低功耗設備或小型 VPS 非常友善。它的官方文件品質相當高，設定選項都有清楚說明，而且提供 authelia validate-config 與 authelia crypto 等命令列工具，讓你在啟動前就能驗證設定與產生密碼雜湊、金鑰。

不過，Authelia 本身「不處理 TLS、不做路由」，你必須先有一個反向代理（Nginx、Traefik、Caddy、HAProxy 都支援），並且在反向代理上設定 forward-auth 的轉發規則。換句話說，Authelia 的部署難度有一部分其實轉嫁到了反向代理的設定上。對已經熟悉 Nginx 或 Traefik 的人來說這不是問題，但對初學者而言，第一次把 forward-auth 接起來的過程可能會比預期花時間。

3-2 設定流程與實際操作體驗

Authelia 的所有設定都集中在一個 YAML 檔案裡，主要區塊包括：authentication_backend（使用者來源）、access_control（存取規則）、session（session 與 cookie 設定）、storage（OIDC 用的儲存）、identity_providers（OIDC 客戶端設定）、regulation（暴力破解防護）、notifier（SMTP 通知）等。整個檔案對一個中型的自架環境來說，大約落在兩百到四百行之間。

這種「設定檔即一切」的模式，優點是透明、可版控、可重現。你可以把整份 YAML 放進 Git，未來要搬家或重建時直接套用即可。設定錯誤時，Authelia 啟動會直接報錯並指出行號，除錯體驗其實不差。但缺點也很明顯：沒有圖形化管理介面。新增使用者要改檔案（或接 LDAP）、調整存取規則要改檔案、新增 OIDC 客戶端也要改檔案，改完之後通常得重啟服務。

對於習慣 GUI 的人來說，這會是一個心理門檻。但換個角度想，Authelia 的設定邏輯其實非常線性：你幾乎可以把它想像成「用 YAML 描述反向代理的存取政策」。一旦理解了 access_control 的規則優先順序（由上而下、first match wins），整個模型就豁然開朗。多數人卡關的地方反而不是 Authelia 本身，而是反向代理那邊的 forward-auth 標頭傳遞與 URL 白名單設定。

另外值得一提的是 Authelia 的 OIDC Provider 設定。它支援授權碼流程（Authorization Code Flow）與 PKCE，也支援 refresh token 與 client credentials 等模式，設定上需要為每個客戶端產生一組密鑰雜湊，並在 YAML 中宣告 redirect URI 與 scope。這部分對第一次接觸 OIDC 的人來說會稍微吃力，但官方文件有完整範例，照著做通常不會出錯。

3-3 整合能力與生態系

Authelia 的整合能力集中在兩個方向：forward-auth 與 OIDC Provider。forward-auth 的覆蓋面非常廣，幾乎任何放在 Nginx、Traefik、Caddy 後面的服務都能被保護，即使該服務本身完全不支援 SSO。這也是 Authelia 在自架圈最受歡迎的原因：你不需要等應用程式支援 OIDC，只要它跑在反向代理後面，就能加上登入與 2FA。

OIDC Provider 則讓支援標準協定的應用程式可以真正實現 SSO。官方文件提供了大量客戶端設定範例，涵蓋 Grafana、Nextcloud、Proxmox、Portainer、Mattermost、Jellyfin、MinIO、Paperless-ngx 等常見服務。不過要注意的是，Authelia 目前不原生支援 SAML 2.0，如果你的環境裡有只吃 SAML 的應用程式（例如某些企業級工具或舊版系統），就得靠其他元件（如 Keycloak、Authentik，或專門的 SAML 代理）來補足。

身份來源方面，Authelia 支援檔案式使用者、LDAP 與 Active Directory，對於已經有既有目錄服務的組織來說相當合適。它也能夠讀取 LDAP 群組，並在存取規則中依據群組做授權判斷。整體來說，Authelia 的整合哲學是「以反向代理為中心」，它的強項是把「沒有 SSO 的服務」也納入保護儔，弱項則是缺乏完整的身份治理與多協定支援。

四、設定難度正面對決：從安裝到上線的真實門檻

談到設定難度，很容易流於「哪個比較難」的籠統結論。但實際上，難度會因為你的背景、環境與需求而異。以下從三個面向分別評估，並在最後給出一個綜合對照表。

4-1 初始部署門檻比較

Authentik 的初始部署需要 PostgreSQL 與 Redis，Docker Compose 範例雖然完整，但如果你是從零開始，要先理解這些元件的角色與連線設定。官方文件對安裝流程寫得清楚，多數人照著做可以在半小時到一小時內把服務跑起來。真正的門檻在「跑起來之後」：你要花時間理解它的事件模型，才能把第一個應用程式接上。

Authelia 的初始部署相對簡單，單一容器加上一份 YAML 就能啟動，而且如果只用檔案式使用者與記憶體 session，連資料庫都不需要。但它的門檻在「反向代理」那邊：你必須在 Nginx 或 Traefik 上設定 forward-auth 的轉發與標頭傳遞，這一步對不熟悉反向代理的人來說，反而比 Authentik 的資料庫設定更難。整體而言，Authelia 的「元件數量」少，但「外部依賴設定」多；Authentik 的「元件數量」多，但「外部依賴設定」相對標準化。

4-2 日常維運與除錯體驗

日常維運是 Authentik 明顯勝出的地方。它提供完整的 Web UI，使用者管理、群組調整、應用程式新增、登入紀錄查詢、稽核日誌，全都可以在介面上完成。要新增一個使用者或重設密碼，不需要碰設定檔，也不用重啟服務。對於多人共用或有頻繁異動需求的環境，這種即時性非常有價值。

Authelia 則完全相反：任何設定變更都要改 YAML 並重啟服務（雖然它支援部分設定熱重載，但主要設定仍需重啟）。對於小型、穩定的環境來說這不是問題，但如果你經常需要新增使用者或調整權限，就會覺得有點綁手綁腳。不過 Authelia 的設定驗證工具相當好用，改壞了會直接告訴你哪裡錯，減少了盲目重啟的時間。

除錯方面，兩者都提供結構化日誌，但 Authentik 的日誌分散在 server、worker、outpost 等多個元件，排查問題時需要對架構有概念；Authelia 的日誌相對集中，且錯誤訊息通常直接指出設定檔的問題所在。對於喜歡「看日誌辦案」的人來說，Authelia 的除錯體驗可能更直覺一些。

4-3 升級與版本演進的風險

兩套系統都在活躍開發中，升級時都可能遇到破壞性變更。Authentik 的升級通常涉及資料庫遷移，官方會在 release notes 中標示需要注意的地方，但由於它功能多、元件多，升級時需要留意的細節也比較多。建議升級前務必備份 PostgreSQL，並在測試環境先驗證一次。

Authelia 的升級相對單純，因為它沒有資料庫遷移的問題（除非你使用 OIDC 與 SQLite），主要風險在設定檔的相容性。官方文件會標示哪些設定選項被棄用或變更，升級後跑一次 validate-config 就能確認。整體來說，Authelia 的升級風險較低，但功能演進的幅度也較小；Authentik 的升級需要更謹慎，但換來的是更快的功能成長。

比較項目

Authentik

Authelia

首次部署複雜度

中（需 PostgreSQL + Redis）

低至中（單容器，視反向代理設定而定）

管理介面

完整 Web UI

無，以 YAML 設定為主

設定變更即時性

高，UI 即時生效

低，多數需修改檔案並重啟

除錯直覺度

中，需理解多層架構

高，錯誤訊息集中明確

升級風險

中至高，需注意資料庫遷移

低至中，主要為設定相容性

資源需求

較高（建議 4GB 記憶體）

低（數百 MB）

五、整合度評比：反向代理、應用程式與身份來源

整合度是選型的另一個關鍵。這裡我們分成三個層次來看：與反向代理的整合、對應用程式的支援廣度，以及身份來源（目錄服務）的整合能力。

5-1 與反向代理的整合

Authelia 在這方面是專家。它原生設計就是為了與 Nginx、Traefik、Caddy、HAProxy 搭配，官方文件對每一種反向代理都有完整的 forward-auth 設定範例，包含需要傳遞的標頭（如 Remote-User、Remote-Groups、Remote-Email）與需要放行的路徑白名單。這種「與反向代理深度綁定」的設計，讓它在保護既有服務時特別順手。

Authentik 同樣支援 forward-auth，但必須透過 Outpost 來實現。Outpost 可以是內嵌模式，也可以是獨立容器；獨立容器模式彈性高，但多了一層網路連線與憑證設定的複雜度。此外，Authentik 的 Outpost 需要在 UI 中與 Application 綁定，設定流程比 Authelia 多幾個步驟。不過換個角度說，Authentik 的 Outpost 架構也更適合分散式部署，例如把不同應用程式的驗證工作分派到不同網路區域。

5-2 對應用程式的支援廣度

兩者對主流自架服務的支援都相當完整，但支援的方式不同。Authentik 原生支援 OIDC、SAML、LDAP 三種協定，對於需要 SAML 的舊系統或企業應用特別有用；Authelia 則以 OIDC 與 forward-auth 為主，不支援 SAML。如果你的環境裡有只吃 SAML 的應用程式，Authentik 會是比較省事的選擇。

在 forward-auth 的覆蓋面上，兩者都能保護「完全不支援 SSO」的服務，但 Authelia 的設定通常比較輕量，因為它不需要額外部署 Outpost。對於家庭實驗室玩家來說，這是一個很實際的差異：Authelia 讓你用最少的元件，把最多服務納入保護；Authentik 則需要多一層部署，但換來更豐富的協定支援與更細緻的政策控制。

5-3 身份來源與目錄整合

Authentik 本身就是一個使用者目錄，內建使用者管理、群組、屬性和稽核，也支援從外部 LDAP 同步使用者（部分功能屬於商業版）。這對於想要「一套搞定」的環境來說很方便，但也意味著你的身份資料會集中在 Authentik 的資料庫裡，備份與遷移需要特別規劃。

Authelia 則刻意不當目錄，它支援檔案式使用者、LDAP 與 Active Directory，把身份資料的管理交給既有的目錄服務。這種設計的好處是「不重複造輪子」，如果你的環境已經有 LDAP 或 AD，Authelia 可以直接沿用；缺點是如果你沒有既有目錄，就得用 YAML 檔案管理使用者，規模一大就會很麻煩。

整合面向

Authentik

Authelia

OIDC Provider

支援

支援

SAML 2.0

原生支援

不支援

LDAP Provider

支援

不支援（僅作為使用者來源）

Forward-Auth

透過 Outpost

原生支援

使用者管理

內建 UI

外部檔案或 LDAP

多因素驗證

TOTP、WebAuthn、Duo

TOTP、WebAuthn、Duo

多租戶品牌

支援

不支援

六、效能、資源佔用與安全性考量

效能方面，Authelia 以 Go 撰寫，啟動快、記憶體佔用低，單一實例通常就能輕鬆處理數百到數千名使用者的驗證請求。若需要高可用，可以搭配 Redis 做 session 共享，並在反向代理層做負載平衡。對於資源有限的環境（例如樹莓派、低功耗迷你主機、入門級 VPS），Authelia 幾乎是首選。

Authentik 以 Python / Django 撰寫，加上 PostgreSQL 與 Redis，資源需求明顯較高。在一般 x86 主機上，一個基礎部署大約會佔用 1 到 2GB 記憶體；若加上 worker 的背景任務與較多使用者，建議準備 4GB 以上。效能上它足以支撐中小型團隊，但如果你追求極致的輕量，Authelia 會更合適。

安全性方面，兩者都支援 TOTP、WebAuthn、Duo 等多因素驗證，也都提供暴力破解防護（Authelia 有 regulation 機制，Authentik 則可透過政策與流程實現）。Authelia 的優點是設定透明、可版控，安全政策一目了然；Authentik 的優點是功能完整，包含稽核日誌、登入紀錄、細緻的政策引擎，對於需要合規或稽核的環境更有幫助。兩者都建議搭配 HTTPS、強制 2FA，並定期更新版本以修補安全漏洞。

七、選型建議：什麼情況該選哪一套？

看完前面的分析，你可能已經隱約感覺到自己比較適合哪一套。以下用情境化的方式，給出更具體的建議。

7-1 適合 Authentik 的情境

如果你需要 SAML 支援、想要完整的使用者管理介面、需要多租戶或品牌設定，或者你的環境裡有多個團隊、多個應用程式需要細緻的政策控制，Authentik 會是比較合適的選擇。它特別適合「把 SSO 當成一個平台來經營」的情境，例如中小企業內部、有多個自架服務的進階玩家，或是有稽核需求的環境。相對地，你必須接受較高的資源需求與較陡的學習曲線。

7-2 適合 Authelia 的情境

如果你追求輕量、快速、設定透明，而且主要需求是「把反向代理後面的服務保護起來」，Authelia 幾乎是無腦首選。它特別適合家庭實驗室、低功耗設備、單人或少數人使用的環境，以及已經有 LDAP 或 Active Directory 的組織。它也很適合當作「入門 SSO」的第一站：先用 Authelia 把 forward-auth 玩熟，未來有需要再升級到功能更完整的方案。

7-3 混合與演進路徑

其實，這兩套並不是互斥的。有些進階玩家會用 Authelia 保護大部分服務，再用 Authentik 處理需要 SAML 或少數需要完整目錄管理的應用程式；也有人先從 Authelia 入門，等需求成長後再遷移到 Authentik。重點是理解自己的需求邊界：你需要的是「一個守門員」，還是「一個身份平台」？答案會決定你該投入哪一套。

使用情境

推薦方案

理由

家庭實驗室、低功耗設備

Authelia

輕量、單容器、資源需求低

需要 SAML 或 LDAP Provider

Authentik

原生支援多協定

已有 LDAP / AD 的組織

Authelia

可直接沿用既有目錄

需要完整使用者管理介面

Authentik

內建 UI 與稽核

只想保護反向代理後方服務

Authelia

forward-auth 原生支援、設定輕量

多團隊、多租戶、需政策控制

Authentik

流程與政策引擎彈性大

八、結語

回到最初的問題：Authentik 與 Authelia，到底哪一套比較好？答案取決於你把 SSO 視為什麼。如果你把它視為「一道守門員」，希望用最少的資源與最透明的設定，把反向代理後面的服務保護起來，Authelia 的輕量與直覺會讓你滿意；如果你把它視為「一個身份平台」，需要多協定支援、完整管理介面與細緻的政策控制，Authentik 的功能深度會讓你覺得值得。兩套都是成熟、活躍、社群支持度高的開源專案，沒有絕對的優劣，只有適不適合。

對剛入門的人，我的建議是：先釐清自己有多少服務需要保護、是否需要 SAML、是否已有目錄服務、主機資源是否充裕。這四個問題的答案，通常就能幫你做出決定。如果你還不確定，不妨先從 Authelia 開始，用 forward-auth 把幾個服務保護起來，體驗 SSO 帶來的便利；等需求成長、發現 Authelia 不足時，再評估是否遷移到 Authentik。這樣的演進路徑，對多數自架玩家來說是最務實的。

無論選擇哪一套，記得做好備份、強制啟用 2FA、定期更新版本，並且在正式上線前先在小範圍測試。SSO 是整個環境的門戶，一旦設定錯誤，影響的會是所有依賴它的服務。花時間把基礎打好，後面的維運就會輕鬆很多。

🏠 返回首頁