امن‌سازی پنل‌های تحت وب روی سرور مجازی با Tinyauth؛ راهنمای عملی و مقایسه با Authelia

اگر روی سرور مجازی ایران خود چند سرویس Self-Hosted مثل Portainer، Grafana، Uptime Kuma، n8n، FileBrowser یا Baserow اجرا می‌کنید، احتمالاً با این چالش روبه‌رو شده‌اید که پنل مدیریتی هرکدام از این ابزارها با یک آدرس اینترنتی جداگانه در دسترس است و هیچ لایه احراز هویت یکپارچه‌ای وجود ندارد. در این مقاله یک راه‌حل سبک و کم‌هزینه را بررسی می‌کنیم: Tinyauth؛ ابزاری که با یک فایل Docker Compose و چند خط تنظیمات، جلوی تمام سرویس‌های وب شما یک صفحه ورود قرار می‌دهد.

هدف این مقاله فقط معرفی Tinyauth نیست. قرار است بفهمیم این ابزار در عمل چه مشکلی را حل می‌کند، چه زمانی انتخاب درستی است و چه زمانی نیست، و چطور می‌توان آن را روی یک VPS لینوکس ایران راه‌اندازی کرد. همچنین تفاوت‌های آن با Authelia را در یک جدول مقایسه‌ای بررسی می‌کنیم تا بتوانید تصمیم آگاهانه‌تری بگیرید.

Tinyauth دقیقاً چه کاری انجام می‌دهد؟

Tinyauth یک میدل‌ور احراز هویت است که توسط Steve Iliopoulos ساخته شده و با زبان Go نوشته شده است. فلسفه طراحی آن ساده است: به‌جای اینکه برای هر سرویس یک سیستم لاگین جداگانه راه‌اندازی کنید، Tinyauth را جلوی همه آن‌ها قرار می‌دهید و کاربر قبل از رسیدن به پنل اصلی، ابتدا باید از Tinyauth عبور کند .

معماری کلی به این شکل است:

User
  ↓
Domain (panel.example.com)
  ↓
Reverse Proxy (Traefik / Caddy / Nginx)
  ↓
Tinyauth (Login Screen)
  ↓
Application (Portainer / Grafana / etc)

Tinyauth نه دیتابیسی برای مدیریت نیاز دارد و نه داشبورد پیچیده‌ای. کل تنظیمات از طریق متغیرهای محیطی انجام می‌شود و می‌توان آن را در کمتر از پنج دقیقه راه‌اندازی کرد .

چرا پنل‌های Self-Hosted بدون احراز هویت خطرناک هستند؟

بسیاری از ابزارهای متن‌باز که روی VPS اجرا می‌شوند، سه حالت دارند:

🔹 سرویس‌هایی مثل Portainer و Grafana که خودشان سیستم لاگین دارند و می‌توان آن‌ها را ایزوله نگه داشت.

🔹 سرویس‌هایی مثل Uptime Kuma و n8n که لاگین دارند اما گاهی کاربران برای راحتی آن را غیرفعال می‌کنند.

🔹 سرویس‌هایی مثل IT-Tools، Whoami یا برخی پنل‌های داخلی که هیچ لایه احراز هویتی ندارند و با دانستن آدرس، هر کسی می‌تواند به آن‌ها دسترسی پیدا کند .

Tinyauth دقیقاً برای دسته سوم طراحی شده: سرویس‌هایی که می‌خواهید سریع و بدون تغییر کد، جلوی آن‌ها یک صفحه ورود قرار دهید.

پیش‌نیازهای راه‌اندازی روی سرور مجازی ایران

برای این آموزش به یک VPS لینوکس نیاز دارید. حداقل مشخصات پیشنهادی:

Tinyauth روی توزیع‌های Ubuntu، Debian، Rocky Linux، AlmaLinux و Fedora Server قابل اجراست. اگر از هاست لینوکس ایران استفاده می‌کنید، معمولاً Ubuntu 22.04 یا 24.04 در دسترس است که انتخاب ایده‌آلی محسوب می‌شود.

مقایسه Tinyauth با Authelia؛ کدام را انتخاب کنیم؟

Authelia یکی از محبوب‌ترین راه‌حل‌های احراز هویت Self-Hosted است، اما برای همه سناریوها مناسب نیست. جدول زیر تفاوت‌های کلیدی را نشان می‌دهد:

نتیجه: اگر چند سرویس روی یک VPS دارید و می‌خواهید سریع و بدون دردسر یک لایه احراز هویت اضافه کنید، Tinyauth انتخاب بهتری است. اگر به RBAC پیچیده، مدیریت متمرکز کاربران و ادغام با LDAP نیاز دارید، Authelia گزینه مناسب‌تری است.

مرحله به مرحله: نصب Tinyauth روی VPS لینوکس

مرحله ۱: اتصال به سرور و به‌روزرسانی

با SSH به سرور متصل شوید (در ویندوز از PuTTY یا PowerShell استفاده کنید):

ssh root@SERVER_IP

سپس سیستم را به‌روزرسانی کنید و ابزارهای پایه را نصب کنید:

apt update && apt upgrade -y
apt install curl wget git nano ca-certificates -y

مرحله ۲: نصب Docker

اگر Docker روی سرور نصب نیست:

curl -fsSL https://get.docker.com | sh
systemctl status docker

برای اطمینان از نصب صحیح، نسخه Docker و Docker Compose را بررسی کنید:

docker --version
docker compose version

مرحله ۳: ساخت کاربر و Secret

Tinyauth از bcrypt برای هش کردن رمز عبور استفاده می‌کند. ساده‌ترین راه ساخت کاربر، استفاده از خود ایمیج Docker است:

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

این دستور از شما نام کاربری و رمز عبور می‌پرسد و در نهایت یک رشته به شکل username:$2a$10$… تولید می‌کند. این مقدار را کپی کنید.

برای ساخت Secret (کلید امضای نشست)، از OpenSSL استفاده کنید:

openssl rand -hex 16

خروجی یک رشته ۳۲ کاراکتری hex است که به‌عنوان SECRET استفاده می‌شود .

مرحله ۴: فایل Docker Compose

یک پوشه برای Tinyauth بسازید و فایل Compose را ایجاد کنید:

mkdir -p /opt/tinyauth && cd /opt/tinyauth
nano docker-compose.yml

محتوای نمونه برای محیط تست (بدون Reverse Proxy):

services:
  tinyauth:
    container_name: tinyauth
    image: ghcr.io/steveiliop56/tinyauth:v3
    restart: unless-stopped
    environment:
      - SECRET=YOUR_32_CHAR_SECRET_HERE
      - APP_URL=http://YOUR_SERVER_IP:3000
      - USERS=youruser:$$2a$$10$$YOUR_BCRYPT_HASH_HERE
    ports:
      - "3000:3000"

مرحله ۵: اجرا و بررسی

docker compose up -d
docker ps

اگر همه‌چیز درست باشد، کانتینر Tinyauth در لیست کانتینرهای فعال نمایش داده می‌شود. برای مشاهده لاگ‌ها:

docker compose logs -f tinyauth

اکنون با مرورگر به آدرس http://SERVER_IP:3000 بروید. باید صفحه ورود Tinyauth را ببینید .

اتصال Tinyauth به Reverse Proxy

Tinyauth به‌تنهایی یک صفحه لاگین است؛ برای محافظت از سرویس‌های واقعی باید آن را به Reverse Proxy متصل کنید. سه گزینه رایج وجود دارد:

Traefik

Traefik یکی از بهترین گزینه‌هاست چون با Docker ادغام طبیعی دارد. برای محافظت از یک سرویس، کافی است لیبل‌های زیر را به کانتینر آن اضافه کنید :

labels:
  - "traefik.http.middlewares.tinyauth.forwardauth.address=http://tinyauth:3000/api/auth/traefik"
  - "traefik.http.routers.myapp.middlewares=tinyauth@docker"

با این کار، کاربر قبل از دسترسی به سرویس اصلی به صفحه لاگین Tinyauth هدایت می‌شود.

Caddy

Caddy با دستور forward_auth از Tinyauth پشتیبانی می‌کند. نمونه Caddyfile:

panel.example.com {
    forward_auth tinyauth:3000 {
        uri /api/auth/caddy
        copy_headers Remote-User
    }
    reverse_proxy app:9000
}

Nginx

برای Nginx از ماژول auth_request استفاده می‌شود. اگر از Nginx Proxy Manager (NPM) استفاده می‌کنید، Tinyauth رسماً پشتیبانی خوبی از آن دارد .

افزودن OAuth (Google یا GitHub) به Tinyauth

از نسخه ۱.۰.۰ به بعد، Tinyauth از OAuth پشتیبانی می‌کند. یعنی می‌توانید به‌جای مدیریت رمز عبور، کاربران را با حساب Google یا GitHub وارد کنید .

برای GitHub، ابتدا در بخش Developer Settings یک OAuth App بسازید. سپس در Docker Compose این متغیرها را اضافه کنید:

environment:
  - GITHUB_CLIENT_ID=your_client_id
  - GITHUB_CLIENT_SECRET=your_client_secret

با این تنظیمات، صفحه لاگین Tinyauth گزینه ورود با GitHub را نمایش می‌دهد .

رفع خطاهای رایج Tinyauth

صفحه Tinyauth باز نمی‌شود

ابتدا بررسی کنید کانتینر فعال باشد و پورت در حال Listen باشد:

docker ps
ss -tulpn | grep 3000
docker compose logs --tail=50

خطای 502 Bad Gateway

این خطا معمولاً یعنی Reverse Proxy نمی‌تواند به Tinyauth یا سرویس مقصد وصل شود. بررسی کنید:

🔹 آیا Tinyauth و Reverse Proxy در یک شبکه Docker مشترک هستند؟

🔹 آیا آدرس http://tinyauth:3000 از داخل کانتینر Reverse Proxy قابل دسترسی است؟

🔹 آیا سرویس مقصد واقعاً روی پورت اعلام‌شده در حال اجراست؟

برای تست دستی:

curl -v http://127.0.0.1:3000

حلقه Redirect (Redirect Loop)

اگر مرورگر بی‌نهایت بین صفحات می‌چرخد، معمولاً مشکل از تنظیمات HTTPS یا Cookie است. بررسی کنید:

🔹 APP_URL با آدرسی که کاربر باز می‌کند مطابقت داشته باشد.

🔹 اگر از HTTPS استفاده می‌کنید، Tinyauth هم باید از HTTPS مطلع باشد.

🔹 Headerهای X-Forwarded-Proto و X-Forwarded-Host توسط Reverse Proxy به‌درستی تنظیم شوند.

نکات امنیتی که نباید نادیده بگیرید

🔹 HTTPS الزامی است. صفحه لاگین Tinyauth را بدون HTTPS روی اینترنت منتشر نکنید. گواهی SSL را با Let’s Encrypt یا سرویس مشابه تهیه کنید.

🔹 فایروال را فراموش نکنید. با UFW فقط پورت‌های ضروری (SSH، HTTP، HTTPS) را باز نگه دارید.

🔹 رمز عبور قوی انتخاب کنید. Tinyauth از bcrypt استفاده می‌کند، اما رمز ضعیف همچنان ضعیف است.

🔹 SSH را محافظت کنید. از SSH Key، Fail2Ban و غیرفعال کردن Root Login در صورت امکان استفاده کنید.

🔹 پورت‌های داخلی را نبندید، فقط از بیرون ببندید. سرویس‌های Docker را روی شبکه داخلی نگه دارید تا فقط Reverse Proxy به آن‌ها دسترسی داشته باشد.

Tinyauth برای چه کسانی مناسب نیست؟

Tinyauth ابزار خوبی است، اما محدودیت‌هایی هم دارد که باید بدانید:

🔹 سرویس‌هایی با WebSocket یا APIهای خاص ممکن است به تنظیمات اضافی Reverse Proxy نیاز داشته باشند.

🔹 محیط‌های سازمانی با نیاز به RBAC پیچیده بهتر است سراغ Authelia یا Keycloak بروند.

🔹 اگر یک سرویس خودش احراز هویت قوی دارد (مثل Grafana با LDAP)، اضافه کردن Tinyauth ممکن است پیچیدگی اضافی ایجاد کند.

جمع‌بندی