VPS 搭建 Authentik 教程：Docker、OIDC、Forward Auth 与备份（2026）

团队在 VPS 上部署的服务越来越多后，最先失控的往往不是 CPU 或磁盘，而是账号：Grafana、Gitea、Nextcloud、内部面板各有一套密码，员工离开时要逐个回收权限，不支持 OIDC 的旧应用又无法统一登录。Authentik 把这些入口收敛到一个身份平台，既能作为 OIDC、SAML、LDAP 提供方，也能通过 Proxy Provider 给没有单点登录能力的 Web 应用增加前置认证。

本文以 Authentik 2026.8.2、Docker Compose、PostgreSQL 16、Caddy 和 Ubuntu 24.04 为基准，在一台 VPS 上完成域名 HTTPS、OIDC 接入、Forward Auth、MFA、备份、升级和故障排查。版本号来自 2026 年 9 月 15 日下载的官方 Compose 文件；实际安装前仍应重新查看官方发行说明。

Authentik 适合什么场景

Authentik 适合已经有多个自托管应用，希望统一登录、二次验证和访问策略的个人站长与小团队：

支持 OpenID Connect/OAuth 2.0、SAML、LDAP 和 SCIM 等常见协议；
可用可视化 Flow 编排登录、注册、密码重置与 MFA 流程；
应用原生支持 OIDC 时，Authentik 直接充当身份提供方；
应用不支持统一登录时，可通过 Proxy Provider 与 Outpost 做反向代理认证；
可按用户、组、属性和策略控制不同应用的访问权限；
一个账号被禁用后，可以集中阻止其继续登录已接入的应用。

它不是密码管理器，也不会替你保存每个网站的个人密码。如果你需要管理团队密码库，可另外部署 Vaultwarden 自托管密码管理器。

Authentik、Keycloak 和简单反代认证怎么选

方案	优点	代价	更适合
Authentik	管理界面直观，协议与代理认证兼顾，Flow 灵活	server、worker、PostgreSQL 和 Outpost 概念较多	自托管应用多、既有 OIDC 又有旧应用
Keycloak	OIDC/SAML 生态成熟，Realm、角色与企业目录能力完整	配置和资源规划更复杂	企业身份、多个组织或复杂角色模型
Authelia	相对轻量，适合给反向代理后的网页加登录	身份平台和应用目录能力较窄	少量内部网页、主要使用 Forward Auth
Basic Auth	配置最快	无统一账号生命周期、MFA 和细粒度审计	临时、低风险、极少用户的页面

如果你更重视 Realm、企业目录和成熟的角色模型，可阅读 Keycloak 单点登录部署指南。若你的主要需求是让不同 Docker 应用快速获得统一登录入口，Authentik 通常更容易起步。

部署架构与 VPS 配置

本文采用单节点结构：

浏览器 / OIDC 应用
        |
        | HTTPS :443
        v
      Caddy
        |
        | HTTP 127.0.0.1:9000
        v
  Authentik server + worker
        |
        | Docker 内部网络 :5432
        v
    PostgreSQL 16

官方把 Docker Compose 安装定位为测试环境和小规模生产环境，最低要求是 2 个 CPU 核心、2GB 内存。2GB 只是能启动的下限；同机还要运行 PostgreSQL、Caddy、worker 和备份任务，实际建议如下：

使用规模	VPS 建议	说明
测试、少于 10 个用户	2 vCPU、2GB 内存、25GB SSD	可验证功能，不建议承担关键登录入口
小团队、几十到数百用户	2–4 vCPU、4GB 内存、40GB NVMe	给数据库、缓存和升级留出余量
登录高峰明显或应用较多	4 vCPU、8GB 以上	先压测，再决定拆分数据库或多节点

单台 VPS 仍是单点故障。Authentik 宕机会影响新登录与授权检查，因此关键业务必须准备异机备份、应急管理员账号和恢复演练，不能把单节点 Compose 当成高可用方案。

准备域名、DNS 与防火墙

为身份入口使用独立域名，例如 sso.example.com，并将 A 记录指向 VPS 公网 IPv4。只有服务器确实配置了可用 IPv6 时才添加 AAAA 记录。

公网只需要开放 SSH、HTTP 和 HTTPS：

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

不要在云安全组或 UFW 中开放 9000、9443 和 5432。本文会把 Authentik 两个宿主机端口绑定到 127.0.0.1，数据库则完全不映射端口。如果防火墙启用后 SSH 中断，先通过服务商控制台处理，再按 UFW 导致 SSH 失联的恢复清单排查。

安装 Docker、Caddy 与基础工具

以下命令以 Ubuntu 24.04 为例。Docker 应按官方仓库安装；已有 Docker 环境不要重复运行来源不明的一键脚本。

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y ca-certificates curl openssl caddy

docker --version
docker compose version
sudo systemctl enable --now caddy

Authentik 官方要求使用 Docker Compose v2。长期运行前还应配置日志轮转、资源监控和恢复演练，可结合 Docker Compose 生产环境清单检查。

下载官方 Compose 并生成密钥

创建部署目录并收紧默认文件权限：

sudo install -d -m 0750 -o "$USER" -g "$USER" /opt/authentik
cd /opt/authentik
umask 077

curl -fsSLo compose.yml https://docs.goauthentik.io/compose.yml

官方说明 Compose 文件会固定下载时的当前 Authentik 版本。不要把镜像标签改成 latest；先保留可审计的版本，再按升级章节有计划地更新。

生成 PostgreSQL 密码和 Authentik Secret Key，同时让两个 Web 端口只监听回环地址：

{
  printf 'PG_PASS=%s\n' "$(openssl rand -hex 32)"
  printf 'AUTHENTIK_SECRET_KEY=%s\n' "$(openssl rand -hex 60)"
  printf 'COMPOSE_PORT_HTTP=127.0.0.1:9000\n'
  printf 'COMPOSE_PORT_HTTPS=127.0.0.1:9443\n'
} > .env

chmod 600 .env
docker compose config --quiet

不要把 .env 提交到 Git、贴到聊天或写进工单。docker compose config 的完整输出会包含展开后的敏感信息，因此这里只使用 --quiet 做语法检查。

官方 Compose 默认把 /var/run/docker.sock 挂载到 worker，以便自动管理 Outpost。获得 Docker Socket 访问权通常等同于拥有宿主机高权限。如果不需要自动管理 Outpost，应删除该挂载并手动部署 Outpost；需要它时，也应考虑只暴露必要 API 的 Docker Socket Proxy，并限制只有 worker 能访问。

另外，不要把宿主机的 /etc/timezone 或 /etc/localtime 挂进 Authentik 容器。官方要求容器保持 UTC，这类挂载可能造成 OAuth、SAML 和证书时间判断异常。

启动 Authentik 并检查状态

拉取固定版本镜像并启动：

cd /opt/authentik
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=200 server worker postgresql

确认端口没有监听公网地址：

ss -lnt | grep -E ':9000|:9443'
curl -fsSI http://127.0.0.1:9000/

ss 输出应显示 127.0.0.1:9000 和 127.0.0.1:9443，不能是 0.0.0.0 或 [::]。若容器不断重启，不要靠 restart 掩盖错误，先查看 PostgreSQL 健康状态和 server/worker 日志。

用 Caddy 提供域名 HTTPS

编辑 /etc/caddy/Caddyfile：

sso.example.com {
    encode zstd gzip
    reverse_proxy 127.0.0.1:9000

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
    }
}

验证并重载配置：

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
curl -fsSI https://sso.example.com/

Authentik 的反向代理必须支持 HTTP/1.1 和 WebSocket，并正确覆盖 Host、X-Forwarded-Host、X-Forwarded-Proto、X-Forwarded-For、Connection 与 Upgrade 等头。Caddy 的 reverse_proxy 会处理常规转发与 WebSocket；不要让客户端绕过 Caddy 直接访问 9000。

如果改用现有 Nginx Proxy Manager，可参考 Nginx Proxy Manager 域名 HTTPS 与反向代理指南，同时确认 WebSocket 已启用。页面无限加载、CSRF 失败、回调变成 HTTP 或日志中的客户端 IP 全错，通常都与代理头或可信代理范围有关。Authentik 默认只信任回环、RFC1918 与链路本地地址来源的转发头，不要为了省事把整个公网加入可信范围。

首次登录与基础安全设置

通过 https://sso.example.com 打开初始化流程，按页面提示为 akadmin 设置强密码。完成后立即执行以下动作：

为日常管理员创建独立账号，不长期共用 akadmin；
给管理员启用 TOTP 或 WebAuthn/Passkey，并保存恢复方式；
为管理员和普通用户分别设置合理的登录 Flow 与密码策略；
创建一个离线保管的应急管理员，定期验证但不要用于日常登录；
检查默认品牌、邮件发送和密码重置流程，避免用户被锁定后只能改数据库；
记录所有依赖 Authentik 的应用，方便故障时判断影响范围。

身份服务应优先保证“可恢复”，而不是只追求登录页好看。没有可用备份、恢复码和应急账号时，MFA 配置失误也可能把管理员自己锁在门外。

接入支持 OIDC 的应用

原生支持 OIDC/OAuth 2.0 的应用应优先使用 OIDC Provider，而不是再套一层代理认证。基本流程如下：

在 Authentik 管理后台创建 OAuth2/OpenID Provider；
选择 Confidential Client，为服务端应用生成 Client ID 与 Client Secret；
将应用文档要求的 Redirect URI 原样加入允许列表，协议、域名、路径和末尾斜杠必须完全一致；
创建 Application 并关联刚才的 Provider；
在目标应用填写 Authentik Provider 页面给出的 Discovery URL、Client ID 与 Client Secret；
先用测试组验证登录、登出、邮箱和组映射，再开放给全部用户。

常用 Scope 至少包括 openid，通常还会使用 profile 与 email。不要手写猜测授权端点和 Token 端点，直接使用 Provider 页面提供的 OpenID Configuration/Discovery 地址。Client Secret 只放在目标应用的服务端配置或密钥管理系统中，不能发送到浏览器端。

出现 redirect_uri_mismatch 时，逐字符比较目标应用实际发送的回调地址与 Authentik 中的允许地址。使用反向代理后出现 http:// 回调，则先修复代理头与外部域名判断，不要把错误的 HTTP 回调加入白名单。

给不支持 OIDC 的应用增加 Forward Auth

旧应用没有 OIDC、SAML 或 LDAP 时，可以创建 Proxy Provider。Authentik 提供完整代理模式和 Forward Auth 模式；已有 Caddy、Nginx 或 Traefik 负责业务流量时，Forward Auth 通常更合适：反向代理把认证请求交给 Outpost，验证通过后仍由原代理访问后端。

Forward Auth 又分为单应用和域级两种：

Single application：每个应用有独立 Provider 和策略，隔离更清晰，优先推荐；
Domain level：同一域名下多个应用共享一次认证，配置更省，但无法为每个应用分别执行不同策略。

配置顺序应是：创建 Proxy Provider、创建 Application、把 Provider 分配给 Embedded Outpost，再按 Authentik 生成的代理片段修改 Caddy/Nginx/Traefik。不要凭记忆抄旧版配置；Outpost 地址、回调路径和认证端点应以当前后台生成内容为准。

Forward Auth 只解决“请求是否允许进入”，不会自动让后端应用认识 Authentik 用户。若后端依赖用户名、邮箱或组头，必须明确允许哪些身份头穿过代理，并在后端阻止客户端直接伪造这些头。

PostgreSQL 与配置备份

至少备份数据库、.env、compose.yml、data/、certs/ 和 custom-templates/。先创建仅管理员可访问的备份目录：

sudo install -d -m 0700 -o "$USER" -g "$USER" /srv/backups/authentik
cd /opt/authentik
set -a
. ./.env
set +a

BACKUP_FILE="/srv/backups/authentik/authentik-$(date -u +%Y%m%dT%H%M%SZ).dump"
docker compose exec -T postgresql pg_dump \
  -U "${PG_USER:-authentik}" \
  -d "${PG_DB:-authentik}" \
  -Fc > "$BACKUP_FILE"

test -s "$BACKUP_FILE"
docker compose exec -T postgresql pg_restore --list < "$BACKUP_FILE" | head
unset PG_PASS AUTHENTIK_SECRET_KEY PG_USER PG_DB

再备份配置和持久化目录：

sudo tar --exclude='*.log' -czf \
  "/srv/backups/authentik/files-$(date -u +%Y%m%dT%H%M%SZ).tar.gz" \
  -C /opt/authentik .env compose.yml data certs custom-templates

备份必须复制到另一台服务器或对象存储；只留在同一块 VPS 磁盘上不能抵御磁盘损坏和误删。数据库转储包含用户和认证数据，应加密、限制读取权限并设置保留周期。每次大版本升级前都要做一次恢复演练，确认备份不是空文件且能在隔离环境导入。

安全升级 Authentik

Authentik 官方不支持降级，而且跨发布序列升级必须逐个主要版本推进：先升级到当前序列的最新补丁版，再进入下一个序列。server 与所有 Outpost 版本也必须一致。

安全升级流程：

cd /opt/authentik

# 先完成数据库和文件备份，再下载新 Compose 到临时文件
curl -fsSLo compose.yml.new https://docs.goauthentik.io/compose.yml
diff -u compose.yml compose.yml.new || true

docker compose -f compose.yml.new config --quiet
mv compose.yml compose.yml.previous
mv compose.yml.new compose.yml

docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=200 server worker postgresql

不要跳过多个版本序列直接升级，也不要看到异常就把旧镜像标签改回来：数据库迁移后强行降级可能进一步破坏数据。正确回退方式是在隔离环境验证后，用升级前的数据库和文件备份恢复整套实例。

常见故障排查

容器启动后反复重启

先检查 Compose 展开和三个核心服务日志：

cd /opt/authentik
docker compose config --quiet
docker compose ps
docker compose logs --tail=300 postgresql server worker

常见原因是 .env 缺少 PG_PASS 或 AUTHENTIK_SECRET_KEY、磁盘已满、数据库卷权限异常，或升级跨度不受支持。

域名能打开但页面一直加载

检查 Caddy 日志、WebSocket 和转发头：

sudo journalctl -u caddy -n 200 --no-pager
curl -fsSI http://127.0.0.1:9000/
curl -fsSI https://sso.example.com/

如果回环地址正常而域名异常，问题通常在 DNS、证书、反向代理或代理头。可按服务已启动但公网无法访问的分层排障方法逐层确认，不要直接关闭 UFW 或把 9000 暴露公网。

OIDC 登录后循环跳转

确认外部访问始终使用同一个 HTTPS 域名，Redirect URI 与应用完全一致，浏览器时间和 VPS 时间正确，并查看 Authentik 与目标应用两侧日志。不要挂载宿主机时区文件，也不要在 HTTPS 页面中配置 HTTP 的 issuer 或 callback。

Outpost 显示离线

检查 Outpost 版本是否与 server 一致、是否能访问 Authentik 外部 URL、Token 是否有效，以及 Docker Socket 或 Socket Proxy 是否按预期可达。升级 server 后忘记同步 Outpost，是常见原因之一。

FAQ

Authentik 至少需要多大 VPS？

官方最低要求是 2 个 CPU 核心和 2GB 内存。仅做测试可从 2GB 起步；小团队生产环境更建议 2–4 vCPU、4GB 内存和 40GB NVMe，并监控登录高峰、数据库增长和备份耗时。

Authentik 可以代替 Keycloak 吗？

两者都能提供 OIDC、SAML 和集中身份管理。Authentik 更强调可视化 Flow 与 Proxy Provider，Keycloak 在 Realm、企业集成和成熟生态方面更强。是否替代取决于应用协议、组织模型和团队维护经验。

9000 和 9443 端口需要开放公网吗？

不需要。本文把它们绑定到 127.0.0.1，公网只开放 80/443，由 Caddy 终止 HTTPS 并反向代理到 9000。PostgreSQL 的 5432 也不应映射到宿主机公网。

应用没有 OIDC 还能接入 Authentik 吗？

可以。使用 Proxy Provider 和 Outpost，通过 Forward Auth 或完整代理模式保护应用。已有反向代理时优先考虑单应用 Forward Auth，以便每个应用分别设置访问策略。

为什么不建议直接挂载 Docker Socket？

Docker Socket 权限很高，被利用后可能控制宿主机容器甚至读取敏感数据。官方 Compose 为自动管理 Outpost 默认挂载它；不需要该能力就删除挂载，需要时则考虑 Docker Socket Proxy 和最小权限隔离。

Authentik 升级失败后可以直接降级镜像吗？

不可以。官方不支持降级，数据库迁移完成后直接切回旧镜像风险很高。应在升级前备份数据库与文件，按发布序列逐步升级；失败时从完整备份恢复，而不是强行降级。

官方资料

方案

优点

代价

更适合

Authentik

管理界面直观，协议与代理认证兼顾，Flow 灵活

server、worker、PostgreSQL 和 Outpost 概念较多

自托管应用多、既有 OIDC 又有旧应用

Keycloak

OIDC/SAML 生态成熟，Realm、角色与企业目录能力完整

配置和资源规划更复杂

企业身份、多个组织或复杂角色模型

Authelia

相对轻量，适合给反向代理后的网页加登录

身份平台和应用目录能力较窄

少量内部网页、主要使用 Forward Auth

Basic Auth

配置最快

无统一账号生命周期、MFA 和细粒度审计

临时、低风险、极少用户的页面

使用规模

VPS 建议

说明

测试、少于 10 个用户

2 vCPU、2GB 内存、25GB SSD

可验证功能，不建议承担关键登录入口

小团队、几十到数百用户

2–4 vCPU、4GB 内存、40GB NVMe

给数据库、缓存和升级留出余量

登录高峰明显或应用较多

4 vCPU、8GB 以上

先压测，再决定拆分数据库或多节点

{ printf 'PG_PASS=%s\n' "$(openssl rand -hex 32)" printf 'AUTHENTIK_SECRET_KEY=%s\n' "$(openssl rand -hex 60)" printf 'COMPOSE_PORT_HTTP=127.0.0.1:9000\n' printf 'COMPOSE_PORT_HTTPS=127.0.0.1:9443\n' } > .env chmod 600 .env docker compose config --quiet

sso.example.com { encode zstd gzip reverse_proxy 127.0.0.1:9000 header { Strict-Transport-Security "max-age=31536000; includeSubDomains" X-Content-Type-Options "nosniff" Referrer-Policy "strict-origin-when-cross-origin" } }

sudo install -d -m 0700 -o "$USER" -g "$USER" /srv/backups/authentik cd /opt/authentik set -a . ./.env set +a BACKUP_FILE="/srv/backups/authentik/authentik-$(date -u +%Y%m%dT%H%M%SZ).dump" docker compose exec -T postgresql pg_dump \ -U "${PG_USER:-authentik}" \ -d "${PG_DB:-authentik}" \ -Fc > "$BACKUP_FILE" test -s "$BACKUP_FILE" docker compose exec -T postgresql pg_restore --list < "$BACKUP_FILE" | head unset PG_PASS AUTHENTIK_SECRET_KEY PG_USER PG_DB

cd /opt/authentik # 先完成数据库和文件备份，再下载新 Compose 到临时文件 curl -fsSLo compose.yml.new https://docs.goauthentik.io/compose.yml diff -u compose.yml compose.yml.new || true docker compose -f compose.yml.new config --quiet mv compose.yml compose.yml.previous mv compose.yml.new compose.yml docker compose pull docker compose up -d docker compose ps docker compose logs --tail=200 server worker postgresql

Authentik 适合什么场景

Authentik、Keycloak 和简单反代认证怎么选

部署架构与 VPS 配置

准备域名、DNS 与防火墙

安装 Docker、Caddy 与基础工具

下载官方 Compose 并生成密钥

启动 Authentik 并检查状态

用 Caddy 提供域名 HTTPS

首次登录与基础安全设置

接入支持 OIDC 的应用

给不支持 OIDC 的应用增加 Forward Auth

PostgreSQL 与配置备份

安全升级 Authentik

常见故障排查

容器启动后反复重启

域名能打开但页面一直加载

OIDC 登录后循环跳转

Outpost 显示离线

FAQ

Authentik 至少需要多大 VPS？

Authentik 可以代替 Keycloak 吗？

9000 和 9443 端口需要开放公网吗？

应用没有 OIDC 还能接入 Authentik 吗？

为什么不建议直接挂载 Docker Socket？

Authentik 升级失败后可以直接降级镜像吗？

官方资料

Loading...

Authentik 适合什么场景

Authentik、Keycloak 和简单反代认证怎么选

部署架构与 VPS 配置

准备域名、DNS 与防火墙

安装 Docker、Caddy 与基础工具

下载官方 Compose 并生成密钥

启动 Authentik 并检查状态

用 Caddy 提供域名 HTTPS

首次登录与基础安全设置

接入支持 OIDC 的应用

给不支持 OIDC 的应用增加 Forward Auth

PostgreSQL 与配置备份

安全升级 Authentik

常见故障排查

容器启动后反复重启

域名能打开但页面一直加载

OIDC 登录后循环跳转

Outpost 显示离线

FAQ

Authentik 至少需要多大 VPS？

Authentik 可以代替 Keycloak 吗？

9000 和 9443 端口需要开放公网吗？

应用没有 OIDC 还能接入 Authentik 吗？

为什么不建议直接挂载 Docker Socket？

Authentik 升级失败后可以直接降级镜像吗？

官方资料