自托管服务一多，先给它们加个统一登录门：tinyauth 部署小记

作者

家里自托管的服务一多，浏览器标签页就开始排队：媒体库、下载器、监控面板、RSS、笔记工具……每个都各自为政，有的自带登录，有的干脆没有。我之前一直靠一层反代和私下记密码凑合，但把入口直接暴露给公网总有些心虚。Authelia、Authentik 都看过，配置厚得像一本手册，光是 LDAP 那一套就把人劝退。最近翻到 tinyauth，号称是“最小的 OpenID Certified 认证服务器”，Go 单二进制、Docker 一行起，正好给 homelab 加一道轻量门。

它是什么

tinyauth 是一个开源的认证/授权中间件，Go 写成，单二进制、无依赖，默认监听 3000 端口。它不替代理端点流量，而是作为 forward-auth 服务挂在 Traefik、Caddy 或 Nginx 后面：用户访问任意受保护子域名时，先被弹到 tinyauth 登录，登录成功后再跳转回原服务。支持的认证源包括本地用户名密码、OAuth 第三方登录（GitHub/Google 等）、LDAP 组 ACL，以及组网工具 API 做用户校验。最新 v5.1.0 在 2026 年 6 月通过了 OpenID Basic OP 认证。

logo

login

这张图就是它的登录页：默认走 OAuth 可选，也可以直接用户名密码。界面没什么花哨，但好处是也几乎没什么学习成本。

为什么选它

我原来的状态是：内网服务靠组网工具回家，外网暴露的只敢放少数几个带自身登录的。问题是，每个服务的用户体系、二步验证、密码强度都不一样，管理起来很碎。 tinyauth 解决的是一个很具体的小痛点：

  • 统一入口：所有子域名共用一套登录态，cookie 写在父域名下，跨子域自动共享。
  • 轻量：一个镜像就起来，不需要 Postgres 集群、不需要 Redis、不需要复杂的 RBAC 配置。
  • forward-auth 不挑食：Traefik 原生支持，Caddy 和 Nginx Proxy Manager 也有官方或社区文档。
  • ACL 够用：可以按用户、按 OAuth 组、按 IP 黑白名单控制谁能访问哪个应用。

它不是身份治理平台，不搞 SSO 大联盟，只是把“谁可以进这个子域名”这件事做得小而稳。

怎么跑起来

官方推荐镜像 ghcr.io/tinyauthapp/tinyauth:v5。起一个最小 compose 大概是这样：

services:
  tinyauth:
    image: ghcr.io/tinyauthapp/tinyauth:v5
    restart: unless-stopped
    environment:
      - TINYAUTH_APPURL=https://auth.example.com
      - TINYAUTH_AUTH_USERS=user:$$2a$$10$$...hash...
    volumes:
      - ./data:/data

先创建用户：

docker run -i -t --rm ghcr.io/tinyauthapp/tinyauth:v5 user create --interactive

终端会提示输入用户名和密码，输出一个 bcrypt 哈希。这里有个坑：compose 里的 $ 要转义成 $$，否则 Docker 会把它当变量替换吃掉。

接着挂到 Traefik 上。关键配置只有两条 label：

traefik.http.middlewares.tinyauth.forwardauth.address: http://tinyauth:3000/api/auth/traefik
traefik.http.routers.whoami.middlewares: tinyauth

第二条挂到你想保护的应用 router 上。访问 whoami.example.com 时，Traefik 会先发请求到 tinyauth 的 /api/auth/traefik 校验当前 session；没登录就返回 401 并跳转到登录页，登录完再自动带回去。

authorize

上图是它作为 OIDC provider 的授权确认页。如果你想让某个服务走真正的 OIDC 登录而不是简单的 forward-auth，tinyauth 也能当身份源用。

几个要注意的坑

  • 域名必须规划好：tinyauth 的 cookie 是写在父域名上的。比如认证服务放在 auth.example.com，受保护服务放在 *.example.com 下，这样登录态才能共享。不要把它直接绑在二级 DDNS 域名上，浏览器 cookie 规则会失效。
  • 受信代理 IP：如果要启用 IP 黑白名单，必须设置 TINYAUTH_AUTH_TRUSTEDPROXIES 指向你的反代容器网段（例如 172.17.0.0/16），否则 tinyauth 拿到的是 Docker 内网 IP，ACL 判断没意义。
  • Docker NAT 问题：Traefik 用默认 bridge 网络时，容器看到的源 IP 可能被 NAT 掉。官方文档建议让 Traefik 跑在 network_mode: host 下，以拿到真实客户端地址。
  • 配置还在活跃变动：v5 之后配置格式和命令行有过调整，升级前一定要看 release note。我倾向于直接锁 v5 标签，减少漂移。
  • AGPL-3.0 授权：如果你修改代码并在网络提供服务，需要开源。普通 homelab 自用不受影响，商业部署要留神。

它不适合谁

tinyauth 不是 Authentik 或 Keycloak 的平替。如果你需要动态用户注册、复杂的组织/角色、审计日志、多因素强认证矩阵，它可能会显得太薄。它的定位很明确：给反代后面那十几个自托管服务，加一道“登录门 + 简单 ACL”，而不是做企业 IAM。

小结

我打算把它放在一个独立的小容器里，后面跟着媒体库、监控面板、RSS 几个服务。不改动任何应用本身的认证逻辑，只是通过反代统一加道门。配置加起来不到二十行，比每个服务各自维护密码要干净得多。homelab 玩到后面，其实缺的往往不是更多功能，而是这种“少即是多”的边界感。

发表评论