这款极简认证神器,拯救你的自托管家庭实验室!
玩自托管(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:tinyauthtinyauth:
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 还是其他神器?欢迎在评论区和星哥聊聊你的踩坑经验!
如果觉得这篇文章对你有帮助,别忘了点个 “赞” 和 “在看”,你的支持是星哥持续挖掘好工具的最大动力!我们下期见~
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.