自架服務 Authentik SSO IdP SAML LDAP

Pocket ID 只解了 Passkey 登入,SAML、LDAP、SSH 還缺三塊:Authentik 2026.5 把企業 IdP 該有的補齊

Pocket ID 用 Passkey 處理了一半的自架 SSO 問題,但 SAML、LDAP、流程客製化、瀏覽器 SSH 這些場景它不碰。Authentik 2026.5 把 Flow Engine、RAC、AKQL 全部搬到 OSS,本文拆解它的架構取捨、與 Keycloak/Authelia 的真實差距,以及部署實務。

自架 SSO 在 2026 年走到了一個分歧點。一邊是 Pocket ID 這種把問題刪到極致的路線:只認 Passkey、只吐 OIDC,一支 Go binary 加 SQLite 就能跑。另一邊是組織規模一旦到位、Pocket ID 就接不住的場景:某個 SaaS 還在用 SAML、舊系統只認 LDAP bind、員工需要從瀏覽器跳進伺服器跑 SSH、合規團隊要求 MFA 條件式套用。這時候 Authentik 不是「Pocket ID 的進階版」,而是另一個物種——它把企業 IdP 的整套需求壓進可以在一臺 VPS 上跑起來的形狀。

Authentik 在 2026 年 5 月發布了 2026.5,這個版本把過去鎖在 Enterprise 授權後面的 Remote Access Control(RAC)跟 AKQL 查詢語言都搬到 OSS,worker 容器透過新的 Rust entrypoint 省下約 200MB 記憶體,整套自架預算進一步壓縮。對於正在思考「Pocket ID 已經不夠用,但 Keycloak 太重」的團隊,這個版本剛好把中間地帶填了起來。

OIDC-only 在企業環境會撞到三堵牆

過去兩年自架圈幾乎把 OIDC 當成 SSO 的代名詞,但實務上會撞牆的場景比想像中多。

第一堵牆是 SAML。AWS IAM Identity Center、Salesforce、Tableau、Workday、GitLab Premium、Atlassian Cloud——這些 SaaS 提供的 SSO 介面到 2026 年仍然以 SAML 為主,OIDC 是備選或根本不支援。一個 IdP 沒辦法吐 SAML assertion,這些服務就只能用本地帳號或第三方雲端 IdP。

第二堵牆是 LDAP。自架圈的 Synology DSM、Samba、Mailcow、Zimbra、舊版的 Mattermost、傳統 ERP,很多都只認 LDAP bind。沒有 LDAP 介面就只能在那些系統各自維護一份帳號。雙向同步的需求在跨團隊環境更常見——HR 系統建了人,IdP 就要同步出去;IdP 停用了帳號,下游系統要跟著鎖。

第三堵牆是條件式 MFA 與流程客製化。合規要求常常不是「全部開 TOTP」這麼單純,而是「從新國家登入時要求 MFA」、「特權帳號每三天重新驗證一次」、「特定群組強制硬體金鑰」。OIDC issuer 規格本身對這些流程毫無定義,IdP 要不要做、能不能做完全看實作。Pocket ID 的設計刻意把這塊砍掉以換取簡潔,這是正確的取捨,但不適用於需要這層彈性的場景。

Flow Engine 是 Authentik 真正的差異化

Keycloak 跟 Authentik 都聲稱「可以客製化登入流程」,但兩邊提供的抽象差異很大。Keycloak 的 authentication flow 是一棵以 execution 為節點的決策樹,要插入新邏輯通常得寫 Java SPI 編譯後丟進 deployments 資料夾,重啟容器才能載入。對只會 Python 跟 YAML 的維運團隊,這條路成本很高。

Authentik 把這層改成 Flow Engine。一個 flow 是由一連串 stage 組成的線性流程,每個 stage 是可重用的元件:identificationpasswordauthenticator_validatecaptchaconsentpromptuser_loginredirect 都是內建的選項。每個 stage 前面可以掛 policy,policy 用簡化的 Python 表達式寫,admin UI 直接編輯。

實際上的差別在於這類需求:「持有公司 email 的使用者免 MFA、外部協作者強制 WebAuthn」。在 Authentik 裡就是給 authenticator_validate stage 掛一條 policy 判斷 request.user.email.endswith('@example.com'),policy 為 false 就跳過該 stage。整個邏輯在 admin UI 上五分鐘設定完,沒有重新編譯也不用重啟容器。

Flow Engine 的另一個好處是除錯介面。Authentik 提供 flow inspector,可以看到當前流程走到哪個 stage、policy 的判斷結果是什麼、context 裡有哪些變數。Keycloak 對應的能力要靠開 debug log 加上自己讀 stack trace。

2026.5 把哪些東西從 Enterprise 搬到 OSS

這次版本最值得注意的不是新功能,而是哪些原本要付費的功能變免費。

Remote Access Control(RAC)是其中最大一塊。RAC 允許從瀏覽器直接連 SSH、RDP、VNC,所有連線都經過 Authentik 認證、套 MFA、留下完整 session 錄影。架構上是用 Apache Guacamole 的協定層,但前端跟認證整合是 Authentik 自己重寫的。把這個功能搬到 OSS 之後,自架族群終於有一個能取代「Bastion 主機加 OpenVPN 加自管 SSH key」傳統做法的選項。

AKQL 是 Authentik 自己的查詢語言,用於後臺搜尋使用者、事件、Log。語法接近 KQL:context.geo.country = 'Taiwan' AND action = 'login_failed'。在事件大量累積後,這比手刻 SQL 查 Postgres 來得實際。2026.5 之前這個語言在 Enterprise 才有,現在全部開放。

另外幾個變動值得提一下。Command Palette 加進來,Cmd/Ctrl+K 可以快速搜尋使用者與動作,對天天要切換頁面的管理員是有感的改善。Authenticator Validation stage 現在可以對 email、SMS OTP 嘗試做頻率限制,不需要再倚靠外部的 fail2ban 或反向代理層。釋出週期從兩個月改為三個月,每次版本能塞進更多收尾,發版品質會比過去穩定。

跟 Keycloak、Authelia 的真實位置

把這三套放在同一張地圖上會比較清楚。

Keycloak 是 Java 應用,預設記憶體佔用約 1.2GB 起跳,realm/client/role 資料模型嚴謹但學習曲線陡。對大型企業、有 Red Hat 採購合約、需要走 OpenShift 整合的場域,它仍然是首選。但對需要在一臺中等規格 VPS 上同時跑十幾個服務的團隊,光 Keycloak 一個就吃掉預算的三分之一。

Authelia 走的是反向代理閘道路線,定位是「Traefik/Nginx 前面那個守門員」。它的 OIDC provider 能力在 v4 之後逐步補上,但本質仍是 forward auth 工具——如果應用本身有 OIDC 客戶端,Authelia 跟 Authentik 都能接;但要做 SAML、LDAP server、SCIM 同步、瀏覽器 SSH,Authelia 完全不在這個射程內。記憶體佔用約 100MB,是這三套裡最輕的。

Authentik 落在中間。記憶體 600-800MB(2026.5 後再省 200MB),全功能 IdP,支援 OIDC、SAML、LDAP outpost、SCIM、WS-Federation。資料模型比 Keycloak 簡潔——只有 Application、Provider、Flow、Policy 四個核心概念。

選擇邏輯其實很清楚:homelab 規模配 Pocket ID 就好,OIDC 應用全包;商業營運且有 SAML 需求就上 Authentik;只需要把 Traefik 後面那批內網工具加一層登入就用 Authelia;公司預算有 Red Hat 訂閱、團隊有 Java 維運能力才考慮 Keycloak。

部署形狀比想像中合理

Authentik 的最小部署需要五個容器:server、worker、PostgreSQL、Redis、外加至少一個 outpost(如果要用 forward auth 或 LDAP)。乍看比 Pocket ID 重很多,但所有元件都可以用標準 docker-compose 拉起來,記憶體加總在 1GB 上下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
services:
postgresql:
image: postgres:16-alpine
volumes:
- ./db:/var/lib/postgresql/data
environment:
POSTGRES_PASSWORD: ${PG_PASS}
POSTGRES_USER: authentik
POSTGRES_DB: authentik

redis:
image: redis:7-alpine
command: --save 60 1 --loglevel warning
volumes:
- ./redis:/data

server:
image: ghcr.io/goauthentik/server:2026.5
command: server
environment:
AUTHENTIK_REDIS__HOST: redis
AUTHENTIK_POSTGRESQL__HOST: postgresql
AUTHENTIK_POSTGRESQL__USER: authentik
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
AUTHENTIK_SECRET_KEY: ${SECRET_KEY}
ports:
- "127.0.0.1:9000:9000"

worker:
image: ghcr.io/goauthentik/server:2026.5
command: worker
environment:
AUTHENTIK_REDIS__HOST: redis
AUTHENTIK_POSTGRESQL__HOST: postgresql
AUTHENTIK_POSTGRESQL__USER: authentik
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
AUTHENTIK_SECRET_KEY: ${SECRET_KEY}

PostgreSQL 跟 Redis 通常可以與其他自架服務共用,前提是有獨立資料庫跟密碼。Outpost 是部署 forward auth 或 LDAP server 介面時才需要的容器,可以從 admin UI 點按鈕自動拉起、也可以手動跑在獨立機器上。建議把 90009443 綁在 127.0.0.1,前面套 Caddy 或 Nginx 處理 TLS 與 HSTS。

資料庫備份這件事務必獨立排程。Authentik 把流程、policy、應用設定全部存在 PostgreSQL,這份資料一旦丟失,整個重建工程比應用本身複雜得多。pg_dump 配合 Restic 推到遠端物件儲存是最不容易出錯的做法。

不適合 Authentik 的場景

不是所有自架族群都應該升級到 Authentik。如果整個自架體系只有 OIDC 應用、使用者人數在十人以內、沒有 SAML 或 LDAP 的需求,Pocket ID 仍然是更合理的選擇——少四個容器、少一份 PostgreSQL 備份、少一份 Flow 設定要維護。

如果認證需求只是「在反向代理層加一道登入」、後端應用根本不知道有 SSO,Authelia 比 Authentik 簡單得多。Authentik 也能做這件事,但要建 Application、設 Provider、跑 Outpost,比 Authelia 直接寫 access_control 規則繁瑣。

最後一個常被忽略的場景:對外開放註冊的服務。Authentik 預設假設使用者由管理員建立或從外部來源同步,自助註冊雖然可以開,但流程複雜度跟攻擊面比想像中高。如果產品本身需要對全網開放註冊,Auth0、Clerk 這類雲端 IdP 處理 fraud detection、bot prevention、社交登入的成熟度是自架方案短時間追不上的。

從 Pocket ID 過渡到 Authentik 的路徑

對已經跑著 Pocket ID 的環境,遷移到 Authentik 不必一次切換。實務上比較順的路徑是兩套並存一段時間:把 SAML 需求、LDAP 需求、需要瀏覽器 SSH 的服務先接到 Authentik,原本接 Pocket ID 的純 OIDC 應用維持不動。確認 Authentik 運行穩定、流程設定到位之後,再把 OIDC 應用一個一個切過去。

切換 OIDC client 的工作量集中在三件事:在 Authentik 建立新的 Provider 與 Application、拿到新的 client ID 與 secret、修改各應用的 OIDC 設定指向新的 issuer URL。每個應用約十分鐘。比較需要注意的是使用者識別欄位——Pocket ID 預設用 email 當 username claim,Authentik 預設給的是 preferred_username,部分應用會把這個變動視為新使用者而把舊資料孤立。在 Authentik 的 Provider 設定裡選擇正確的 sub mode 可以避開這個坑。

結語

Authentik 不會取代 Pocket ID,兩者解決的問題層級不同。Pocket ID 是給「只想登入按鈕簡單一點」的場景,Authentik 是給「企業 IdP 該做的事一個都不能少」的場景。2026.5 把 RAC 跟 AKQL 搬到 OSS 之後,自架 SAML 與 LDAP 提供者的門檻降到歷史新低,過去得倚靠 Keycloak 或雲端 IdP 才做得到的事,現在一臺中等規格 VPS 上跑得起來。

NCSE Network 提供位於臺灣是方電訊機房的 VPS 主機,採用 Intel Gold CPU 與 NVMe SSD,搭配 99% SLA 與多上游 IP Transit。Authentik 配 PostgreSQL 跟 Redis 的工作負載對磁碟 I/O 與網路延遲敏感,這類「整套自架基礎建設」適合放在穩定可預期的環境。需要為團隊架設一臺承載 SSO、SAML、LDAP 與內部應用閘道的 VPS,可以到 ncse.tw 瞭解 VPS 與相關方案。

需要穩定的雲端主機?

NCSE Network 提供企業級 VPS,7 天免費試用,臺灣是方電訊機房,99% SLA 保證。

查看 VPS 方案 →