Bedrud از چندین روش احراز هویت پشتیبانی می‌کند.

JWT (JSON Web Tokens)

Bedrud از JWT برای مدیریت جلسه استفاده می‌کند. هنگام ورود، سرور دو توکن برمی‌گرداند:

۱. Access Token: کوتاه‌مدت (مثلاً ۱ ساعت). برای دسترسی به endpointهای محافظت‌شده استفاده می‌شود. ۲. Refresh Token: طولانی‌مدت (مثلاً ۳۰ روز). برای دریافت Access Token جدید بدون نیاز به ورود مجدد استفاده می‌شود.

سرور این توکن‌ها را در internal/middleware/auth.go تأیید می‌کند.

مدیریت توکن و امنیت

۱. استراتژی جفت توکن (Rotation)

Bedrud از یک استراتژی امن rotation توکن استفاده می‌کند. وقتی کاربر احراز هویت می‌شود، دریافت می‌کند:

• Access Token: با HS256 امضا شده، شامل شناسه کاربر، نام و دسترسی‌ها. برای مدت کوتاهی معتبر است (از طریق tokenDuration پیکربندی می‌شود).
• Refresh Token: یک توکن طولانی‌مدت جداگانه.

Rotation: وقتی Access Token منقضی شود، کلاینت Refresh Token را به /api/auth/refresh ارسال می‌کند. سرور یک جفت token کاملاً جدید صادر می‌کند و refresh token ذخیره‌شده در database (پایگاه داده) را به‌روزرسانی می‌کند. این کار احتمال سوءاستفاده را حتی در صورت سرقت token کاهش می‌دهد.

۲. ابطال توکن (Blacklisting)

برای پشتیبانی از خروج امن، Bedrud یک Token Blacklist پیاده‌سازی کرده است.

• وقتی کاربری خارج می‌شود، Refresh Token فعلی او به جدول blocked_refresh_tokens اضافه می‌شود.
• قبل از refresh هر جلسه، سرور این جدول را بررسی می‌کند. اگر توکنی مسدود باشد، درخواست فوراً رد می‌شود.
• یک task (وظیفه) پس‌زمینه (Scheduler) توکن‌های مسدود شده را پس از انقضای طبیعی‌شان پاک‌سازی می‌کند.

۳. ساختار Claims توکن JWT

توکن‌ها متادیتایی حمل می‌کنند که به backend و frontend اجازه می‌دهد بدون کوئری به database تصمیم‌گیری سریع انجام دهند:

{
  "userId": "uuid-string",
  "email": "user@example.com",
  "name": "Display Name",
  "accesses": ["user", "admin"],
  "exp": 123456789,
  "iat": 123456780
}

روش‌های احراز هویت

۱. ایمیل و رمز عبور محلی

• رمزهای عبور با bcrypt هش می‌شوند — هرگز به صورت متن ساده ذخیره نمی‌شوند.
• هنگام ثبت‌نام، یک record (رکورد) جدید User در database ایجاد می‌شود.

۲. ورود اجتماعی (OAuth2)

Bedrud از کتابخانه Goth برای پشتیبانی از:

• Google
• GitHub
• Twitter

برای فعال‌سازی، بخش auth: در config.yaml را با Client ID و API Secret خود پر کنید.

۳. Passkeyها (WebAuthn/FIDO2)

Bedrud از احراز هویت بدون رمز عبور بر اساس استاندارد FIDO2 (WebAuthn) پشتیبانی می‌کند.

• فرآیند ثبت‌نام: ۱. شروع: سرور یک Challenge رمزنگاری‌شده تولید کرده و در جلسه کاربر ذخیره می‌کند. ۲. پایان: authenticator کلاینت (مثلاً TouchID، YubiKey) challenge را امضا می‌کند. سرور attestation را تأیید، Public Key را استخراج و در جدول passkeys ذخیره می‌کند.
• فرآیند احراز هویت: ۱. شروع: سرور یک challenge جدید صادر می‌کند. ۲. پایان: کلاینت challenge را با کلید خصوصی خود امضا می‌کند. سرور Public Key را از database بازیابی، امضا را تأیید و Sign Counter را بررسی می‌کند.
• امنیت: بررسی فیلد Counter از حملات Replay جلوگیری می‌کند. اگر counter دستگاه authenticator از counter ذخیره‌شده بیشتر نباشد، ورود رد می‌شود.

۴. ورود مهمان

به کاربران اجازه می‌دهد فقط با یک نام فوراً به جلسه بپیوندند. سرور یک record کاربر موقت با نقش guest ایجاد می‌کند.

تأیید ایمیل

وقتی requireEmailVerification: true در تنظیمات باشد، ثبت‌نام و ورود محلی (غیر OAuth) نیاز به تأیید ایمیل دارند:

• ثبت‌نام کاربر را ایجاد می‌کند اما EmailVerifiedAt را روی nil تنظیم می‌کند. کاربر تا زمان تأیید نمی‌تواند وارد شود.
• ورود برای حساب‌های تأییدنشده 403 با {"requiresVerification": true} برمی‌گرداند.
• ارسال مجدد از طریق POST /api/auth/verify/resend — محدود شده توسط verificationEmailCooldownMins و یک سطل محدودیت نرخ جداگانه (authResendMaxRequests).
• پاکسازی خودکار حساب‌های تأییدنشده را پس از unverifiedAccountTTLHours (پیش‌فرض 48 ساعت، 0 برای غیرفعال‌سازی) حذف می‌کند.
• تغییر ایمیل یک جریان تأیید جدید را راه‌اندازی می‌کند. کاربر وارد سیستم باقی می‌ماند؛ توکن جدید صادر می‌شود.

کاربران مهمان معاف هستند — آنها ایمیل ندارند.

بازنشانی رمز عبور

جریان بازنشانی رمز عبور (نیازمند SMTP):

1. POST /api/auth/forgot-password با {"email": "..."} — سرور لینک بازنشانی را به ایمیل ارسال می‌کند
2. POST /api/auth/reset-password با {"token": "...", "newPassword": "..."} — رمز عبور جدید تنظیم می‌کند

TTL توکن بازنشانی توسط resetTokenTTLHours (پیش‌فرض ۱ ساعت) کنترل می‌شود. نقطه پایانی forgot-password سطل محدودیت نرخ احراز هویت را به اشتراک می‌گذارد.

خنک‌سازی و محدودیت نرخ

Bedrud از چهار سطل محدودیت نرخ جداگانه استفاده می‌کند:

سطل روی 0 = غیرفعال. همه محدودیت‌ها به ازای هر IP راه دور. درخواست‌های بیش از حد 429 Too Many Requests را با هدر Retry-After برمی‌گردانند.

همکاری‌پذیری و CORS

Bedrud برای دسترسی از چند origin طراحی شده است — این موضوع برای توسعه (development) و محیط عملیاتی (production) حیاتی است.

• سیاست CORS: در config.yaml تعریف شده. از AllowCredentials: true پشتیبانی می‌کند که برای session cookieهای استفاده‌شده در OAuth و فرآیندهای Passkey لازم است.
• Originهای مجاز: به‌طور پیش‌فرض، domain خود سرور و localhost:3000 (پورت React dev server) مجاز هستند.

نقش‌های کاربر (کنترل دسترسی)

هر کاربر دارای یک آرایه accesses است که می‌تواند همزمان شامل چندین سطح دسترسی باشد. claims توکن JWT شامل آرایه کامل accesses است که به میان‌افزار اجازه می‌دهد مجوزهای جزئی را بررسی کند.

سطوح دسترسی

سلسله مراتب نقش‌ها

superadmin > admin > moderator > user > guest

یک superadmin می‌تواند هر اقدام مدیریتی را در هر اتاقی بدون نیاز به ارتقا به عنوان moderator اتاق انجام دهد. سازندگان اتاق به طور خودکار مدیر اتاق هستند و می‌توانند شرکت‌کنندگان را به moderator ارتقا دهند.

تخصیص نقش‌ها

نقش‌ها از طریق چندین کانال مدیریت می‌شوند:

• CLI: bedrud user create (ایجاد به عنوان user)، bedrud user promote (افزودن superadmin)، bedrud user demote (حذف superadmin)
• داشبورد مدیریت: صفحه جزئیات کاربر دارای دکمه‌های ارتقا/تنزل است
• API مدیریت: PUT /api/admin/users/:id/accesses با آرایه accesses مورد نظر
• درون جلسه: سازنده اتاق می‌تواند شرکت‌کنندگان را به moderator سطح اتاق ارتقا دهد

توجه: هیچ نقطه پایانی API یا رابط وب برای ایجاد اولین superadmin وجود ندارد. پس از نصب، باید از CLI (bedrud user create + bedrud user promote) برای راه‌اندازی دسترسی اولیه superadmin استفاده کنید. این یک اقدام امنیتی عامدانه است.