Keycloak 啟動就吃 1.5GB RAM、Authelia 連 admin UI 都沒有：Authentik 2026.5 把 IdP 與遠端桌面收進同一支服務

自架一套 SSO 在 2026 年仍然是個尷尬的決定。Keycloak 開機就要 1.5GB RAM、設一支 OIDC application 要點過五六個 tab；Authelia 輕巧但根本沒有 admin UI，所有設定都靠 YAML 寫死，使用者也得另外接 LDAP 才有得管。介於兩者之間、又能扛得起公司級身份驗證（OIDC、SAML、LDAP、RADIUS、SCIM）的選擇，這幾年慢慢收斂到 Authentik 身上。2026.5 在 5 月 22 日釋出，把核心 worker 換成 Rust 入口，每個容器又省下約 200MB 記憶體，把這套自架 IdP 的硬體門檻再往下壓了一截。

Authentik 在 IdP 光譜上的位置

把市面上能自架的開源 IdP 拉出來排，光譜兩端很清楚。

Keycloak 是 Red Hat（現在 IBM）支持的老牌方案，協定覆蓋最完整，從 OIDC、SAML、Kerberos 到 WS-Federation 一應俱全，但代價是吃資源。一個基本配置至少要 1.25GB RAM 才跑得動，JVM 啟動秒數可觀，admin console 介面停留在十年前的設計風格，第一次設定 OIDC 整合預期得花 2 到 4 小時才能跑通。

Authelia 走另一個極端，定位是「forward-auth proxy 的身份層」，搭 Caddy、Traefik、Nginx Proxy Manager 一起用。本身沒有使用者資料庫、沒有 admin UI，所有設定改 YAML 後重啟，使用者來源得從 LDAP 或檔案系統撈。家用實驗室、技術人自架，這個選擇剛剛好；要進到企業情境就力不從心。

Authentik 補的就是這塊中間地帶。Python/Django 寫的 server、Go 寫的 outpost、2026.5 起換成 Rust 入口的 worker，整套服務在 200MB 到 500MB RAM 區間就能跑。協定支援與 Keycloak 接近——OIDC、SAML 2.0、LDAP、RADIUS、SCIM、WS-Federation（2026.2 加入）都齊全；admin UI 是現代化的 React 介面，建立一個 OIDC application 大約 5 分鐘可以完成。

如果只需要 OIDC + passkey、規模很小，Pocket-ID 那種極簡方案就夠用；一旦需要 SAML、LDAP outpost、或者要把幾十支應用集中到同一個帳號體系，Authentik 才是合理的選擇。

Outpost 是這套架構真正的差異點

Authentik 不是把所有功能都塞進核心 server，而是用 Outpost 模式把外圍協定切成獨立微服務。Core 只負責 UI、身份驗證流程、與 PostgreSQL 互動；Outpost 則是部署在邊緣的小型 Go binary，透過 WebSocket 與 Core 保持連線，實際處理協定流量。

目前可用的 Outpost 包含 Proxy（反向代理形式做 forward-auth）、LDAP（把 Authentik 對外暴露成 LDAP server，給只會講 LDAP 的舊系統用）、RADIUS（給 VPN、Wi-Fi、Switch 用）、以及 RAC（瀏覽器內的遠端桌面）。

這個拆法有幾個實際好處。Proxy outpost 可以部署到應用旁邊降低延遲；LDAP outpost 如果要服務內網設備，可以放在內網 VLAN，不需要把 Core 暴露出去；協定層出問題重啟單一 outpost 不會中斷整個 IdP。對只跑一臺 VPS 的小團隊來說，所有 outpost 都可以塞進同一臺機器；規模大了再拆出去就行，架構不用重來。

Proxy outpost 特別值得提一下。它本質上是個 forward-auth 中介，使用者請求進來時先丟到 Authentik 驗證，成功才放行到後端應用。這對那些原生沒有 OIDC 支援的舊系統——例如某些只認 HTTP Basic Auth 的內部工具、或者只有「管理員密碼」概念的 NAS 管理介面——非常有用。把這類服務藏在 Proxy outpost 後面，等於白嫖一層 SSO 與 MFA。

2025 到 2026 的開源節奏

值得留意的是 Authentik 這幾個版本把企業功能逐步往社群版下放的軌跡。

2025.2 把 RAC 從企業版搬到開源版。RAC 全名是 Remote Access Control，本質上是個瀏覽器內的 RDP/SSH/VNC client，使用者透過 Authentik 登入後直接在瀏覽器開啟遠端連線，背後走的是 Guacamole 協定。對需要給外部廠商、約聘人員存取內部主機的場景非常實用——權限收回只要在 Authentik 停用帳號，不用追蹤誰還留著 SSH key。

2026.2 加入了 WS-Federation 支援、SCIM provider 過濾、以及 Object Lifecycle Management（定期排程審核應用與群組權限）。SCIM 過濾在多租戶 SaaS 整合場景是剛性需求，過去要靠自訂腳本。

2026.5 的重點是性能與體驗。Worker 換成 Rust 入口後，每個 worker container 記憶體降低約 200MB，PostgreSQL 連線數也少一個。AKQL（Authentik Query Language）從企業版搬到所有人都能用，可以在 admin UI 直接寫類 SQL 查詢撈 log 和 user。Command Palette 加入 Ctrl + K 快捷鍵搜尋頁面、動作、使用者，對熟手非常有感。

這個節奏比 Keycloak 那種「企業版功能永遠在企業版」的策略友善得多。

Docker Compose 部署一份能跑生產的 Authentik

下面這份設定足以撐起小型團隊使用，分成 server、worker、PostgreSQL、Redis 四個容器：

services:
  postgresql:
    image: docker.io/library/postgres:16-alpine
    restart: unless-stopped
    volumes:
      - database:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: ${PG_PASS}
      POSTGRES_USER: authentik
      POSTGRES_DB: authentik

  redis:
    image: docker.io/library/redis:7-alpine
    restart: unless-stopped
    command: --save 60 1 --loglevel warning
    volumes:
      - redis:/data

  server:
    image: ghcr.io/goauthentik/server:2026.5
    restart: unless-stopped
    command: server
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
    ports:
      - "127.0.0.1:9000:9000"
    depends_on: [postgresql, redis]

  worker:
    image: ghcr.io/goauthentik/server:2026.5
    restart: unless-stopped
    command: worker
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
    user: root
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    depends_on: [postgresql, redis]

volumes:
  database:
  redis:

幾個重點需要注意：

AUTHENTIK_SECRET_KEY 用 openssl rand -base64 60 產生，遺失等於所有 session、token 全部失效，請放進密碼管理工具。Worker mount docker.sock 是為了讓 Authentik 自動部署 outpost 容器；不需要這個功能可以拿掉，改成手動部署 outpost。Server 只 bind 在 127.0.0.1:9000，前面一定要有反向代理處理 TLS——直接把 IdP 暴露在公網沒上 HTTPS 是災難。

還有一個 2026.5 的 breaking change 要留意：預設監聽位址從 0.0.0.0 改成 [::]，純 IPv4 的環境記得在 ports binding 明確指定 IPv4 位址，否則容器外連不進去。

第一次啟動後造訪 /if/flow/initial-setup/ 建立 admin 帳號，整個流程不會超過十分鐘。

把第一支應用接過來

以 OIDC 串接為例（SAML 流程類似）。在 admin 介面建立一個 Provider（類型選 OAuth2/OpenID），設定好 redirect URI、scope（一般是 openid profile email）、signing key 用 Authentik 內建的 self-signed 或自帶憑證皆可。接著建立一個 Application 綁定這個 Provider，給它一個 slug（會變成 URL 的一部分）。

拿到 client_id、client_secret、以及 well-known 端點 https://idp.example.tw/application/o/<slug>/.well-known/openid-configuration，就可以填進目標應用的 OIDC 設定。

進階一點的場景會用到 Policy Binding——例如「只有 admins 群組可以存取 Forgejo」、「下班時段不允許登入 Grafana」、「來自非臺灣 IP 強制要求 MFA」。這些都是在 Application 上綁 Policy 達成，不需要改動應用本身的程式碼。

實際導入時建議第一個對接的目標選 Forgejo、Grafana、Outline 這類 OIDC 支援成熟的服務，踩坑機率最低。等流程熟了再去處理那些 SAML only 的舊系統。

OIDC 設定上有幾個常見地雷值得提醒。Redirect URI 在 Authentik 採嚴格比對，多一個斜線或 http/https 不一致都會被擋下，部署到正式網域前務必確認協定一致。Token signing 演算法預設是 RS256，要與接收端對齊，部分舊版函式庫只支援 HS256，這時可以在 Provider 層改設定。Logout 流程在 OIDC 規範下有 RP-Initiated Logout 與 Back-Channel Logout 兩種模式，前者讓使用者瀏覽器主動通知 IdP 登出，後者由 IdP 主動推送通知到應用——服務數量多的時候後者比較可靠，但需要每支應用都支援。

把帳號邏輯收進一個位置才有意義

自架 IdP 的價值不在「我也有 SSO 了」，而是當公司內部跑著 Forgejo、Grafana、Portainer、Outline、Vaultwarden 十幾支服務時，使用者只記一組密碼、MFA 設定統一在一個地方、員工離職只需要在 Authentik 停用帳號，所有應用同步失去存取權。這件事在使用者超過五個人之後，省下的維運成本遠超過架一臺 VPS 跑 Authentik 的代價。

Authentik 對硬體要求並不高——2 vCPU、2GB RAM 的小型 VPS 就足以服務數十人團隊。但 IdP 屬於「掛了所有應用都登不進去」的核心服務，主機穩定性與機房網路品質遠比規格本身重要。NCSE Network 在臺灣是方電訊機房提供 Intel Gold CPU 與 NVMe SSD 的 VPS 方案，配上多線 IP Transit 與低延遲線路，適合作為這類 always-on 身份服務的長期落腳處。準備把分散在各家 SaaS 的帳號收回自己控制範圍的團隊，可以從一臺小規格 VPS 開始，逐步把第一支、第二支應用接過來。