Tinyauth部署全攻略：为NAS应用打造安全外网登录防护

December 1, 2025

在先前的内容中，我们曾详细介绍过众多Docker应用，其中部分应用内置了前端身份验证功能。以网络附加存储设备为例，其网页管理界面本身具备登录认证机制，并且支持配置双重验证以增强各类网页服务的安全性。再如QBittorrent、Transmission和Emby这类常见Docker服务，它们也自带了登录验证模块。然而，许多轻量级工具类服务（例如IT-Tools等）可能缺乏此类防护，一旦他人知晓您的服务域名，便可能无需验证直接访问。

本文我们将深入探讨一款中间层认证服务——Tinyauth，它能够有效保护我们的应用服务免受未授权访问。通过下方的动态演示图，您可以直观感受其运作效果。

请注意，Tinyauth目前处于积极开发阶段，其配置参数可能会频繁调整。

在更新前，请务必详细阅读官方发布说明。若仅限个人使用，Nginx、Caddy或Lucky等工具内置的BasicAuth功能通常已足够便捷。

由于Lucky自带认证模块，且Tinyauth官方文档明确指出其对Nginx Proxy Manager有良好兼容性，因此我们将延续上一篇文章的思路，基于NPM进行配置优化。

Lucky的认证界面如下所示。如果您认为其功能已满足需求且对界面美观度要求不高，则无需额外部署Tinyauth。但若您希望集成Google或GitHub等第三方登录方式，本项目将是一个理想选择。

Tinyauth 概述

Tinyauth是一款采用Go语言编写的轻量级身份认证中间件，主要应用于自托管或容器化环境，旨在为网页应用快速增添访问控制层。它无需修改原有应用代码，仅需通过反向代理工具（如Traefik、Nginx、Caddy）进行接入，即可实现登录保护功能。

核心特性

轻量简洁：仅需单个二进制文件即可运行，无额外依赖项，系统资源占用极低。
即开即用：配置过程简单明了，常见应用场景仅需设置环境变量即可完成部署。
多种认证方式：支持传统的用户名密码验证，同时兼容OAuth登录协议（如Google、GitHub）。
反向代理友好：可与Traefik、Nginx、Caddy等主流代理工具无缝集成，适用于家庭实验室及企业级小型应用。
Cookie统一认证：基于域名设置Cookie，实现在同一主域名下多个应用的单一登录体验。

适用场景

为个人NAS服务（例如QNAP）增加外网访问安全层。
保护内部管理工具（如Portainer、Grafana、Whoami等）的访问权限。
在家庭实验室或小型团队项目中快速部署身份验证，无需构建复杂的OAuth服务体系。

部署前准备

我们需要预先生成用户名与密码的哈希值，以及一个32字节的随机密钥。

通过SSH工具连接至NAS设备，依次输入以下命令。请将生成的内容复制保存以备后续使用。具体操作可参考下方示意图。

docker run -it –rm ghcr.io/steveiliop56/tinyauth:v3 user create –interactive

安装与配置步骤

首先创建一个专用网络，以便需要反向代理的应用与NPM保持连通。

查阅官方文档后，我推荐使用以下代码进行配置。请注意，我在此创建了专属的网桥连接。

services:
  app:
    image: jc21/nginx-proxy-manager:latest
    container_name: npm
    restart: always
    environment:
      TZ: Asia/Shanghai
      DISABLE_IPV6: "true"
    volumes:
      - /share/Container/npm/data:/data
      - /share/Container/npm/letsencrypt:/etc/letsencrypt
    ports:
      - "81:81"      # NPM管理面板（仅限内网访问）
      - "8442:80"    # 公网HTTP端口（使用非标准端口）
      - "8443:443"   # 公网HTTPS端口（使用非标准端口）
    networks:
      - npm-net

  tinyauth:
    image: ghcr.io/steveiliop56/tinyauth:v3
    container_name: tinyauth
    restart: always
    environment:
      - APP_URL=https://auth.19960509.xyz:8443    # 通过NPM的8443端口访问
      - USERS=ydxian:$$2a$$10$$9Yc/rH90cPJEJjemF6oRmu9tbnClFyDhjSSjlRyJFPstuFqxr45Ky
      - SECRET=597c4353178836b87f78c5588fc6fc60
    networks:
      - npm-net
    ports:
      - "5202:3000"

networks:
  npm-net:
    external: true

需要注意的是，在国内使用非标准端口号时，APP_URL参数需完整填写地址。

将上述代码适当修改后，打开Container Station创建新的应用程序。

成功启动后的日志参考如下。

反向代理设置

此步骤为必需操作。

打开NPM管理界面，为Tinyauth配置反向代理。按照下图所示填写相关信息后保存。请特别注意不要勾选“Block Common Exploits”选项，因为启用后nginx将禁止在查询参数中使用URL，而这是Tinyauth正常运行所必需的。

再次编辑这条反向代理规则。由于我们在上一篇文章中已申请泛域名证书，此次配置将更为便捷。确认无误后保存即可。

接下来，在浏览器中输入域名加上8443端口即可访问Tinyauth服务。

为应用添加验证层

我的主NAS中部署了IT-Tools万能工具箱，该服务本身不包含登录认证功能，我们以此为例进行演示。

为方便容器间通信，部署代码如下：

services:
  it-tools:
    image: ghcr.io/corentinth/it-tools:latest
    container_name: it-tools
    ports:
      - "8864:80"
    networks:
      - npm-net
    restart: always

networks:
  npm-net:
    external: true

重复前述步骤，为该服务配置反向代理。然后编辑代理规则，将以下内容修改后粘贴至相应区域并保存。需要修改的位置已用中文标注，修改完成后建议删除所有注释文字。

# 根路径位置
location / {
  # 将请求转发至应用
  proxy_pass           $forward_scheme://$server:$port;
  # 在此添加其他应用特定配置
  # Tinyauth认证请求
  auth_request        /tinyauth;
  error_page 401 = @tinyauth_login;
}

# Tinyauth认证请求
location /tinyauth {
  # 将请求转发至Tinyauth
  proxy_pass http://tinyauth:3000/api/auth/nginx;
  # 传递请求头信息
  proxy_set_header x-forwarded-proto $scheme;
  proxy_set_header x-forwarded-host $http_host;
  proxy_set_header x-forwarded-uri $request_uri;
}

# Tinyauth登录重定向
# 请将下方域名修改为您自己的Tinyauth服务地址
location @tinyauth_login {
  return 302 https://auth.xxx.xyz:8443/login?redirect_uri=$scheme://$http_host$request_uri;
}

切换至最后一栏，将参数编辑后粘贴至框内并保存。

在浏览器中输入域名访问工具箱。

由于缓存问题，我将浏览器从Chrome切换至Safari进行测试。实际上，开启无痕模式也能验证效果。系统将自动跳转至认证界面，其响应速度十分迅捷，操作过程流畅顺滑。

输入先前通过SSH设置的账户密码（注意不要输入哈希值），按回车键登录。如下图所示，点击继续按钮。

随后即可成功进入应用界面。

总结建议

如果您的NAS设备主要在国内使用，且仅需基础验证功能，建议直接使用Lucky内置的认证方案。

若您希望集成Google等第三方登录服务，并追求更美观的界面设计，Tinyauth将是一个值得尝试的选择。