使用TinyAuth实现任意应用登录认证
碎碎念
这篇文章刚一发布程序更新了,所以该文章也需要更新,一般这种更新我是懒得管的,奈何这玩意才几天时间,没办法,只能更新一下咯~
中秋月圆,人月两团圆,先祝大家中秋快乐!🥮
入职华为的第三天,团队氛围比想象中更好,大家都很专业也很热心。虽然节奏有点紧,但真心希望能顺利通过考核,留下来继续学习更多硬本领。
转眼国庆假期也要结束啦。因为人在外地,这个假期基本都窝在床上刷电影、鼓捣电脑。于是趁机研究了一下TinyAuth,发现网上资料并不多,于是决定写一篇文章,把自己的研究过程记录下来,也许能帮到同样需要的人。
程序介绍
TinyAuth是一个基于nginx层面的轻量级验证器,理论上可适配任何Web应用。相比nginx自带的auth_basic机制只能通过配置文件维护用户与密码的方式进行简单验证,TinyAuth在此基础上提供了一个更美观的可视化登录界面,并支持更灵活的身份验证方式。
类似于oauth2-proxy这类反向代理验证方案,TinyAuth同样能实现统一登录入口与第三方认证对接。但它更轻量、部署更简单,且无需复杂的反向代理规则。除了支持第三方登录外,TinyAuth还内置了本地账号密码登录功能,并可与自建的登录页面或通行证系统(如Casdoor)无缝衔接,真正实现了“即插即用”的验证体验。
除此之外,TinyAuth在使用体验与可扩展性上也做了不少优化。它支持通过环境变量或配置文件快速定义登录方式、验证规则及跳转逻辑,无需繁琐配置即可接入任意Docker化应用。同时,前端界面采用现代化设计风格,可自定义、标题与背景,融入现有系统的视觉体系。
在性能层面,tinyauth内存占用极小,个位数占用,所以基本上不会对服务器造成负担,TinyAuth依托nginx原生反向代理能力,响应速度与原生访问无异。整个验证流程既安全又高效,非常适合中小型自建服务或私有部署场景。无论是为单一应用增加登录保护,还是构建统一认证入口,TinyAuth都可以提供一个优雅、实用且可拓展的解决方案。
使用方法
提供一个测试页面,欢迎大家尝试使用!已经接入本站自建清羽通行证,支持多种登录方式,欢迎尝试哦!
清羽通行证账号在本平台各处通用账号,包括但不限于评论系统等程序。
部署
该程序的部署和需要加密的程序是解耦的,所以可以先随意部署,这里介绍docker直接部署和1Panel第三方应用部署。
Docker
在文档中实际介绍了该程序的部署,但是写的还不是很完善,你可以选择docker命令部署,如下:
1 | docker run -d \ |
其中变量可能有点不清晰,所以我做了以下变量表。
在最新的v4版本,移除了相关的GENERIC配置,而改成了完全通用项,中间的变量你可以自行设置,用于作为Provider_ID使用,用于组成相关的redirect_url等参数,示例如下:
PROVIDER_ID值设置为casdoor,对应参数如下:
PROVIDER_CASDOOR_NAME:Casdoor 应用名称PROVIDER_CASDOOR_REDIRECT_URL:Casdoor 回调 URLPROVIDER_CASDOOR_CLIENT_ID:Casdoor Client IDPROVIDER_CASDOOR_CLIENT_SECRET:Casdoor Client SecretPROVIDER_CASDOOR_AUTH_URL:Casdoor 认证 URLPROVIDER_CASDOOR_TOKEN_URL:Casdoor 令牌 URLPROVIDER_CASDOOR_USER_URL:Casdoor 用户信息 URLPROVIDER_CASDOOR_SCOPE:Casdoor 作用域
其主城的回调URL值需要设置为:${APP_URL}/callback/${PROVIDER_ID}
所有变量表示例如下:
| 配置变量 | 说明 |
|---|---|
APP_URL | 用于重定向与 Cookie 域名的应用地址 |
SECRET | 用于加密 Cookie 的密钥 |
USERS | 用逗号分隔的 Tinyauth 本地用户列表 |
USERS_FILE | 存放用户列表的文件路径 |
SECRET_FILE | 存放密钥的文件路径 |
COOKIE_SECURE | 是否仅在 HTTPS 下发送 Cookie |
DISABLE_CONTINUE | 是否禁用继续(continue)屏幕 |
OAUTH_WHITELIST | 允许使用 OAuth 登录的用户名列表(可用正则) |
SESSION_EXPIRY | 会话与 Cookie 的过期时间(秒) |
LOG_LEVEL | 日志等级(0–5,对应 debug 到 fatal) |
APP_TITLE | 登录界面的标题文本 |
LOGIN_MAX_RETRIES | 登录失败后最大重试次数 |
LOGIN_TIMEOUT | 账户锁定时长(秒) |
FORGOT_PASSWORD_MESSAGE | 忘记密码界面显示的自定义提示 |
OAUTH_AUTO_REDIRECT | 登录时自动重定向至 OAuth 提供方(none、github、google、generic) |
BACKGROUND_IMAGE | 登录界面的背景图片 URL |
PROVIDER_GITHUB_CLIENT_ID | GitHub OAuth 的 Client ID |
PROVIDER_GITHUB_CLIENT_SECRET | GitHub OAuth 的 Client Secret |
PROVIDER_GITHUB_CLIENT_SECRET_FILE | 存放 GitHub Secret 的文件路径 |
PROVIDER_GOOGLE_CLIENT_ID | Google OAuth 的 Client ID |
PROVIDER_GOOGLE_CLIENT_SECRET | Google OAuth 的 Client Secret |
PROVIDER_GOOGLE_CLIENT_SECRET_FILE | 存放 Google Secret 的文件路径 |
PROVIDER_GENERIC_CLIENT_ID | 通用 OAuth 提供方的 Client ID |
PROVIDER_GENERIC_CLIENT_SECRET | 通用 OAuth 的 Client Secret |
PROVIDER_GENERIC_CLIENT_SECRET_FILE | 存放通用 OAuth Secret 的文件路径 |
PROVIDER_GENERIC_REDIRECT_URL | 通用 OAuth 的重定向 URL |
PROVIDER_GENERIC_AUTH_URL | 通用 OAuth 的认证接口 URL |
PROVIDER_GENERIC_TOKEN_URL | 通用 OAuth 的 Token 获取 URL |
PROVIDER_GENERIC_USER_URL | 通用 OAuth 的用户信息 URL |
PROVIDER_GENERIC_SCOPE | 通用 OAuth 授权作用域 |
PROVIDER_GENERIC_NAME | 登录界面通用 OAuth 按钮显示名称 |
PROVIDER_GENERIC_SKIP_SSL | 是否忽略通用 OAuth 服务器的自签名证书验证 |
LDAP_ADDRESS | LDAP 服务器地址 |
LDAP_BIND_DN | LDAP 绑定使用的 DN |
LDAP_BIND_PASSWORD | LDAP 绑定密码 |
LDAP_BASE_DN | LDAP 搜索基础 DN |
LDAP_INSECURE | 是否跳过 LDAP 服务器证书验证 |
LDAP_SEARCH_FILTER | LDAP 搜索用户时使用的过滤条件 |
如果你只是需要自己的一个身份,你可以直接设置用户名和密码,并且绑定github即可,如果你是自建的通行证,你可以选择Generic认证,其中用不到的配置项可以删掉,下面文档为英文版,标注是否必须配置项,可以搭配一起使用。
相比于docker命令,我更加推荐docker-compose,可以保存部署参数,方便调试和查阅,compose文件如下:
1 | services: |
如果一切正常,容器应该就启动啦,注意绑定个域名,和APP_URL参数保持一致即可。
应用商店
在上篇文章曾介绍了如何添加三方应用商店,这里就不重复了,首先按照以下教程安装三方应用商店:
安装好后,在应用商店直接搜索安装即可,更加快捷,应用商店仅适配使用一种认证方式,如果需要多种认证同时添加请自行使用以上docker部署。
使用
其中LDAP和Oauth2.0部分的配置这里不再细讲,基本上都是通用的协议,这里讲一下如何将其接入到1Panel的任意应用吧,1panel采用的是Openresty,和nginx的配置基本兼容,所以是通用的,如果是其他平台可以自行类比。
首先使用1Panel自带的反向代理部署应用,这都是通用步骤,建议自行配置反向代理,而不是1Panel创建网站中的一键部署按钮:
这样可以将反代相关配置放在一个单独的配置文件中,改动更小,不同于一键部署,一键部署的配置文件包括反代部分均为单文件,改动起来有点麻烦,当然也是可以实现的,可以仅仅改动反向代理部分即可。
下面修改Nginx配置文件,进入以下菜单,点击源文按钮实现修改:
这里在修改之前应该是/,而不是/manifest.json,并且正常反代这里只有一个反向代理,所以放心点即可!
修改配置文件为如下配置:
1 | # =============================== |
其中的http://127.0.0.1:8082是我的需要保护的应用和端口,http://127.0.0.1:14389为TinyAuth应用的地址,走内网速度会更快,所以建议本机部署,最下面的sso.liushen.fun请替换为自己部署的tinyauth外部访问地址。
如果不出意外,此时访问这个应用的地址,会自动跳转到tinyauth地址,实现登录后会自动跳转回来,注意由于Cookie保存的位置是当前根目录,所以请使用同一根目录的子域名部署被保护应用和TinyAuth。
总结
TinyAuth为应用提供了一种简单却高效的安全防护手段。它让原本没有登录功能的对外开放应用,也能轻松具备访问验证能力,从而有效防止滥用与未授权访问,显著提升系统的整体安全性。配合自建的通行证系统,更能实现全站统一身份认证,让使用体验与安全管理兼得。
转眼间,国庆与中秋的双节假期也告一段落。短短几天,或许没有太多波澜,但能放松心情、做点喜欢的事,就是一种难得的治愈。愿大家在假期的余温中,继续带着热情与希望,迎接新的生活与挑战。诸君共勉!
每日一图
图片来自哲风壁纸
















