خادم tinyauth: منظومة مصادقة موحدة ومعتمدة للمختبرات المنزلية والخوادم الذاتية

تفرض حماية الخدمات الرقمية في الشبكات المنزلية والخاصة معضلة تقنية متكررة على المهندسين. تتطلب منصات إدارة الهوية المؤسسية الكبرى مثل Keycloak بيئة تشغيل جافا ثقيلة تستهلك بسهولة أكثر من جيجابايت من الذاكرة العشوائية قبل معالجة أول طلب تسجيل دخول. كما تتطلب منصات مثل Authentik بيئات متعددة الطبقات تتألف من قواعد بيانات PostgreSQL وخوادم وسيطة Redis وخيوط معالجة Celery لمجرد التحقق من هوية بضعة مستخدمين.

يعالج مشروع tinyauth، المنشور تحت رخصة البرمجيات الحرة AGPL-3.0، هذا التشتت في الموارد. بني النظام بلغة Go في ملف تنفيذي ثابت ومستقل يتضمن محرك SQLite مدمجا، ليستهلك أقل من 50 ميجابايت من الذاكرة العشوائية مع نيل الاعتماد الرسمي كخادم مصادقة معتمد وفق مواصفات OpenID Connect الأساسية (OpenID Certified Basic OP).

ما هو خادم tinyauth

خادم مستقل وخفيف الوزن للتحقق من الهوية وإدارة صلاحيات الوصول صمم لحماية التطبيقات الداخلية والخوادم المنزلية. يعمل النظام بأسلوبين تشغيليين في آن واحد: كمزود هوية قياسي (Identity Provider) يدعم بروتوكول OpenID Connect للتطبيقات الحديثة، وكركيزة تحقق وسيطة (ForwardAuth) للبروكسيات العكسية لحماية الخدمات التي تفتقر للمصادقة المدمجة.

رغم انخفاض استهلاكه لموارد النظام، يتضمن tinyauth دعما مدمجا لأحدث آليات الأمان الرقمي، مثل مفاتيح المرور المشفرة FIDO2 WebAuthn، والمفاتيح الفيزيائية، ورموز التحقق الثنائي المبنية على الوقت (TOTP)، وربط تسجيل الدخول عبر حسابات خارجية مثل GitHub وGoogle، وإدارة الأدوار والصلاحيات بدقة.

لماذا لم تسمع عنه من قبل

توزعت برمجيات إدارة الهوية في مجتمع الاستضافة الذاتية تاريخيا بين قطبين: أنظمة مؤسسية معقدة صممت لفرق الامتثال في الشركات الضخمة، أو شفرات تحقق وسيطة غير رسمية تفتقر للاختبارات المعيارية والاعتمادات القياسية.

برز مشروع tinyauth عبر الالتزام الصارم بالمعايير المفتوحة. ففي يونيو 2026، اجتاز الإصدار v5.1.0 من tinyauth الاختبارات الرسمية لمؤسسة OpenID Foundation ونال الاعتماد القياسي، مما أثبت أن خوادم المصادقة الخفيفة قادرة على تحقيق أعلى مستويات الدقة والامتثال للبروتوكولات دون الحاجة لبنى تحتية معقدة.

كيف يعمل النظام برمجيا

يفصل tinyauth مسار التحقق من الهوية إلى طبقتين تشغيليتين: طبقة الربط القياسي عبر بروتوكول OpenID Connect، وطبقة فحص الترويسات للبروكسي العكسي:

حماية الخدمات عبر وسيط التوثيق ForwardAuth

تحتوي العديد من الأدوات المفيدة في المختبرات المنزلية، مثل واجهات أجهزة التوجيه ولوحات التحكم البرمجية، على أنظمة مصادقة بدائية أو تفتقر تماما لكلمات المرور.

عند استخدام tinyauth، تعيد البروكسيات العكسية مثل Traefik أو Caddy توجيه الطلبات الواردة إلى tinyauth للتحقق من هوية الزائر قبل السماح بمرور الحركة للخدمة الداخلية. إذا كانت جلسة المستخدم صالحة، يجيب الخادم بكود 200 ويحقن الترويسات التعريفية (Remote-User, Remote-Email, Remote-Groups). يوفر هذا جدار حماية موحدا لخدمات المختبر المنزلي مثل Vaultwarden أو واجهات أجهزة التوجيه، بينما تستفيد التطبيقات الداعمة لبروتوكول OIDC مثل Immich من رموز التوثيق المعتمدة.

بنية قاعدة البيانات المدمجة SQLite

على عكس المنصات التي تلزمك بتثبيت خوادم قواعد بيانات منفصلة، يعتمد tinyauth على محرك SQLite مدمج يعمل بوضع التسجيل المسبق (WAL). تحدث التحديثات الهيكلية تلقائيا فور تشغيل الحاوية. كما أن إنشاء نسخة احتياطية لكامل مستودع الهويات يتطلب نسخ ملف واحد فقط هو /app/data/tinyauth.db، مما يزيل تأخير الاتصالات الشبكية بين الخدمات.

جدول المقارنة الهندسية

مقارنة خادم tinyauth مع منصات إدارة الهوية البديلة

خطوات التشغيل عبر دوكر

يمكن تشغيل خادم tinyauth بحاوية واحدة خفيفة عبر ملف Docker Compose يحدد مجلدا دائما لحفظ البيانات:

services:
  tinyauth:
    image: ghcr.io/tinyauthapp/tinyauth:latest
    container_name: tinyauth
    restart: unless-stopped
    ports:
      - "3000:3000"
    volumes:
      - ./data:/app/data
    environment:
      - APP_URL=https://auth.homelab.internal
      - SECRET_KEY=generate_a_random_32_character_hex_key_here
      - LOG_LEVEL=info
      - REGISTRATION_ENABLED=false

ولحماية خدمة داخلية خلف بروكسي Caddy عبر وسيط التوثيق، يمكن إضافة التوجيه التالي:

app.homelab.internal {
    forward_auth http://tinyauth:3000 {
        uri /api/v1/forward-auth
        copy_headers Remote-User Remote-Email Remote-Groups
    }
    reverse_proxy http://internal-service:8080
}

ما الذي تستبدله المنصة

تستبدل المنصة حزم إدارة الهوية الثقيلة التي ترهق عتاد الخوادم المنزلية المتواضعة. وتلغي الحاجة لإدارة خوادم PostgreSQL وRedis المنفصلة لمجرد تسجيل الدخول، مع توفير بديل معتمد رسميا يحل محل الشفرات البرمجية غير المختبرة.

القيود التقنية الحالية

1. إدارة الهوية للشركات الضخمة متعددة المستأجرين: صمم tinyauth للأفراد والعائلات وفرق التطوير الصغيرة، ولا يحتوي على منظومة العزل الشاملة لآلاف المستأجرين التي توفرها Keycloak.
2. المعالجة المخصصة لرموز التحقق: تسمح البرمجيات المؤسسية الكبرى بتشغيل شفرات جافا سكريبت مخصصة لتعديل رموز التحقق عند إصدارها، بينما يمنع tinyauth ذلك لحماية استقرار النظام.
3. البروتوكولات القديمة: يدعم النظام معايير OAuth2 وOIDC الحديثة، لكنه لا يدعم بروتوكولات قديمة مثل WS-Federation أو Kerberos SPNEGO المعقدة.

الفئات المستفيدة

يعد خادم tinyauth خيارا مثاليا لأصحاب المختبرات المنزلية والمطورين ومهندسي الأنظمة الذين يبحثون عن نظام تسجيل دخول موحد وموثوق يدعم مفاتيح المرور دون استهلاك مفرط للذاكرة أو تعقيد تشغيلي غير مبرر.

الخلاصة

يؤكد مشروع tinyauth أن الأمان والالتزام بالمعايير القياسية لا يتطلبان بالضرورة برمجيات معقدة وضخمة. فمن خلال حصوله على الاعتماد الرسمي لمواصفات OpenID ودعمه المدمج لمفاتيح المرور واستهلاكه المتواضع للذاكرة، يمثل الخادم أساسا متينا لبناء أنظمة التحقق في بيئات الاستضافة الذاتية الحديثة.

المصادر

• مستودع tinyauth على GitHub
• سجل إصدارات tinyauth v5.2.0 على GitHub
• رخصة البرمجيات AGPL-3.0 لمشروع tinyauth
• الموقع الرسمي والتوثيق لمنصة tinyauth
• دليل اعتمادات مؤسسة OpenID Foundation