这款极简认证神器，拯救你的自托管家庭实验室！

这款极简认证神器，拯救你的自托管家庭实验室！

玩自托管（Homelab）的朋友，大概都经历过这种“绝望”：

家里 NAS、软路由、各种 Docker 服务，少说也有十几个应用。Nextcloud、Gitea、Jellyfin、Home Assistant……每个都有自己的登录页。

“能不能搞个统一认证（SSO）？”

你兴冲冲地去搜，大佬们推荐 Authentik 或者 Authelia。结果一上手，好家伙！Authentik 动辄 Docker Compose 拉起五六个容器，还要外挂 PostgreSQL 数据库、跑个 Django 管理后台。光是配环境、调参数，半天就没了，低配小主机更是直接被吃满内存。

难道个人玩家就不配拥有轻量级的统一认证吗？

今天星哥给大家挖到的这个宝贝叫 tinyauth，它完美诠释了什么叫“大道至简”。

什么是 tinyauth？

讲真，tinyauth 的定位非常粗暴：你能找到的最小的认证授权服务器。

没有花里胡哨的依赖，没有复杂的数据库。它就是一个用 Go 语言写的单静态二进制文件。

• 配置极简：全靠环境变量，或者直接在 Docker Labels 里写。
• 存储极简：内置 SQLite，数据全在一个文件里。
• 兼容性拉满：Traefik、Caddy、Nginx、Envoy 四大反向代理通吃。

这项目开源才 15 个月，GitHub 上就狂揽了 7000+ Star，说明自托管社区对“极简认证”的需求有多旺盛。

docker-compose安装

# docker-compose.yml — 最小可运行配置
services:
traefik:
    image:traefik:v3.6
    command:--api.insecure=true--providers.docker
    ports:
      -"80:80"
    volumes:
      -/var/run/docker.sock:/var/run/docker.sock

whoami:
    image:traefik/whoami:latest
    labels:
      traefik.enable:true
      traefik.http.routers.whoami.rule:Host(`whoami.example.com`)
      traefik.http.routers.whoami.middlewares:tinyauth

tinyauth:
    image:ghcr.io/steveiliop56/tinyauth:v5
    environment:
      -TINYAUTH_APPURL=https://tinyauth.example.com
      -TINYAUTH_AUTH_USERS=user:$$2a$$10$$UdLYoJ5lgPsC0RKqYH/jMua7zIn0g9kPqWmhYayJYLaZQ/FTmH2/u
    volumes:
      -./data:/data
    labels:
      traefik.enable:true
      traefik.http.routers.tinyauth.rule:Host(`tinyauth.example.com`)
      traefik.http.middlewares.tinyauth.forwardauth.address:http://tinyauth:3000/api/auth/traefik

三个服务，全部在 Docker 里跑。

用户访问 whoami.example.com 时，Traefik 先把请求转发给 tinyauth 做认证，认证通过才放行。

不通过则 302 重定向到 tinyauth 登录页。

核心玩法：它是怎么工作的？

tinyauth 的核心机制是 Forward Auth（转发认证）。

说白了，它不直接去改你后端应用的代码，而是站在反向代理的后面当保安。

浏览器 → 反向代理(Traefik) → 问 tinyauth：“这人能进吗？”
                                    ↓
                              检查 Cookie/会话
                                    ↓
                         已认证 → 放行      未认证 → 踢去登录页

你只需要在反向代理里配几行规则，用户访问你的应用时，代理会先拦截请求去问 tinyauth。认证通过了，再把你放行到真正的 Jellyfin 或 Gitea。

支持的认证方式，麻雀虽小五脏俱全：

1. 本地用户：支持 bcrypt 密码哈希，还能开启 TOTP 二步验证（手机验证码）。
2. OAuth 登录：支持 Google、GitHub、GitLab 等。最爽的是支持邮箱域名白名单（比如只允许 @gmail.com 登录）。
3. LDAP 接入：如果你公司有现成的 AD 域，直接对接，还支持 mTLS 客户端证书。
4. 自己当 OIDC 服务端：这个最牛！它不仅能做客户端，自己还能作为 OIDC Provider，给其他应用发 Token，支持完整的 Authorization Code Flow + PKCE。

权限控制：指哪打哪

给应用加认证只是第一步，“谁能访问什么应用” 才是核心。

tinyauth 的访问控制是按应用粒度的，而且对 Docker 玩家极其友好。你甚至不需要去 tinyauth 的主配置里写一堆规则，直接在应用的 docker-compose.yml 里加几个 Labels 就搞定了：

jellyfin:
  image: jellyfin/jellyfin
  labels:
    # 开启 tinyauth 认证
    tinyauth.http.middlewares.tinyauth.forwardauth.address: http://tinyauth:3000/api/auth/traefik
    # 只允许 alice 和 bob 访问
    tinyauth.users.allow: "alice,bob"
    # 或者限制特定的 OAuth 分组
    tinyauth.oauth.groups: "media-users"

除了用户和分组，它还支持 IP 黑白名单（比如内网 IP 免密直接进，外网 IP 必须登录）、路径正则过滤，甚至能给不支持认证的老古董应用自动注入 Basic Auth Header。

为什么它这么小？

作为技术人，星哥扒了一下它的源码，发现作者在工程实现上确实下了功夫，堪称 Go 语言自托管工具的典范：

1. Pure Go SQLite：用了 modernc.org/sqlite，纯 Go 实现，不需要 CGO！这意味着你编译出来的二进制文件，扔到任何 Linux 机器上都能直接跑，不用操心 glibc 版本问题。
2. Docker SDK 自动发现：它通过 Docker SDK 直接读取同网络下容器的 Labels。你在应用里配好 Label，tinyauth 自动识别，省去了手动维护域名映射的麻烦。
3. 三阶段 Dockerfile：前端用 Bun 构建，然后 Go 编译，最后塞进 Alpine。前端 SPA 通过 embed 包直接打进 Go 二进制里。最终产物，真的就只有一个可执行文件。
4. 类型安全的 SQL：用了 sqlc 生成 Go 代码，配合 golang-migrate 管理数据库版本，代码洁癖患者看了直呼舒适。

避坑指南与注意事项

虽然 tinyauth 很香，但折腾前星哥还是得提醒几句：

• 开源协议注意：README 里写的是 AGPL v3.0。这玩意传染性很强，自己家里玩、公司内部用没问题；但如果你要魔改后对外提供网络服务，或者二次分发，必须开源你的代码。商用需谨慎！
• 内存状态：它的防暴力破解（登录失败锁定）记录是存在内存里的（最多 256 条），重启就清空。作者觉得这是临时数据无所谓，但如果你环境频繁重启，要注意这点。
• 活跃开发中：作者明确说了“配置可能频繁变更”。升级版本前，一定要看 Release Notes，别盲目无脑 docker pull。
• OAuth 无 2FA：目前 TOTP 二步验证只支持本地用户，OAuth 和 LDAP 登录的用户暂时不支持 2FA。

总结

如果你受够了给每个自托管应用单独建用户，又觉得 Authentik 太重、Authelia 配置太繁琐，那么 tinyauth 绝对是你目前的最优解。

它不追求大而全的企业级复杂策略，而是精准打击了个人玩家和小团队的痛点：极简、轻量、开箱即用。

GitHub 仓库地址：

github.com/tinyauthapp/tinyauth （注：原文部分地方写的是 steveiliop56，请以最新官方仓库 tinyauthapp 为准）

官方文档：
tinyauth.app

你家里的自托管应用统一认证用的什么方案？是 Authelia、Authentik 还是其他神器？欢迎在评论区和星哥聊聊你的踩坑经验！

如果觉得这篇文章对你有帮助，别忘了点个 “赞” 和 “在看”，你的支持是星哥持续挖掘好工具的最大动力！我们下期见~ 👋