Bedrud birden fazla kimlik doğrulama yöntemini destekler.

JWT (JSON Web Tokens)

Bedrud oturum yönetimi için JWT kullanır. Giriş sırasında sunucu iki jeton döndürür:

1. Erişim Jetonu (Access Token): Kısa ömürlü (ör. 1 saat). Korumalı API uç noktalarına erişmek için kullanılır.
2. Yenileme Jetonu (Refresh Token): Uzun ömürlü (ör. 30 gün). Tekrar giriş yapmadan yeni bir Erişim Jetonu almak için kullanılır.

Arka uç bu jetonları internal/middleware/auth.go dosyasında doğrular.

Jeton Yönetimi ve Güvenlik

1. Jeton Çifti Stratejisi (Rotasyon)

Bedrud güvenli bir jeton rotasyonu stratejisi kullanır. Bir kullanıcı kimlik doğrulaması yaptığında şunları alır:

• Erişim Jetonu: HS256 ile imzalanmış olup kullanıcı kimliği, adı ve izinlerini içerir. Kısa bir süre için geçerlidir (tokenDuration ile yapılandırılır).
• Yenileme Jetonu: Ayrı, uzun ömürlü bir jeton.

Rotasyon: Erişim Jetonu sona erdiğinde, istemci Yenileme Jetonunu /api/auth/refresh uç noktasına gönderir. Sunucu daha sonra yepyeni bir jeton çifti yayınlar ve veritabanında saklanan yenileme jetonunu günceller. Bu, bir jeton çalınmış olsa bile fırsat penceresini sınırlar.

2. Jeton İptali (Kara Liste)

Güvenli oturum kapatmayı desteklemek için Bedrud bir Jeton Kara Listesi uygular.

• Bir kullanıcı oturumu kapattığında, geçerli Yenileme Jetonu blocked_refresh_tokens tablosuna eklenir.
• Herhangi bir oturumu yenilemeden önce sunucu bu tabloyu denetler. Bir jeton engellenmişse, istek hemen reddedilir.
• Bir arka plan görevi (Zamanlayıcı), engellenen bu jetonları doğal olarak sona erdikten sonra temizlemek üzere tasarlanmıştır.

3. JWT Claims Yapısı

Jetonlar, arka ucun ve ön ucun veritabanı sorgusu yapmadan hızlı kararlar almasını sağlayan meta veriler taşır:

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

Kimlik Doğrulama Yöntemleri

1. Yerel E-posta ve Parola

• Parolalar bcrypt ile hashlenir - asla düz metin olarak saklanmaz.
• Kayıt olduğunuzda, veritabanında yeni bir Kullanıcı kaydı oluşturulur.

2. Sosyal Giriş (OAuth2)

Bedrud, şu sağlayıcıları desteklemek için Goth kütüphanesini kullanır:

• Google
• GitHub
• Twitter

Bunları, config.yaml dosyanızdaki auth: bölümüne İstemci Kimliğinizi ve API Gizli Anahtarınızı girerek etkinleştirebilirsiniz.

3. Passkey’ler (WebAuthn/FIDO2)

Bedrud, FIDO2 standardı (WebAuthn) aracılığıyla parolasız kimlik doğrulamayı destekler.

• Kayıt Seremonisi:
  1. Başlangıç: Sunucu kriptografik olarak güvenli bir Challenge üretir ve kullanıcının oturumunda saklar.
  2. Bitiş: İstemcinin kimlik doğrulayıcısı (ör. TouchID, YubiKey) challenge’ı imzalar. Sunucu kanıtı (attestation) doğrular, Açık Anahtarı çıkarır ve passkeys tablosuna kaydeder.
• Kimlik Doğrulama Seremonisi:
  1. Başlangıç: Sunucu yeni bir challenge yayınlar.
  2. Bitiş: İstemci, özel anahtarıyla challenge’ı imzalar. Sunucu veritabanından Açık Anahtarı getirir, imzayı doğrular ve İmza Sayacını (Sign Counter) denetler.
• Güvenlik: Counter alanının eşleştirilmesi Tekrar Oynatma Saldırılarını (Replay Attacks) engeller. Kimlik doğrulayıcının sayısı saklanan sayıdan yüksek değilse, giriş reddedilir.

4. Misafir Girişi

Kullanıcıların yalnızca bir adla anında bir toplantıya katılmasına olanak tanır. Sunucu guest rolüyle geçici bir kullanıcı kaydı oluşturur.

E-posta Doğrulama

Yapılandırmada requireEmailVerification: true olduğunda, yerel (OAuth olmayan) kayıt ve giriş işlemleri e-posta onayı gerektirir:

• Kayıt kullanıcıyı oluşturur ancak EmailVerifiedAt’i nil olarak ayarlar. Kullanıcı doğrulanana kadar giriş yapamaz.
• Giriş doğrulanmamış hesaplar için 403 ve {"requiresVerification": true} döndürür.
• Yeniden gönder POST /api/auth/verify/resend ile — verificationEmailCooldownMins ve ayrı bir hız sınırlama kovası (authResendMaxRequests) tarafından sınırlanır.
• Otomatik temizlik unverifiedAccountTTLHours (varsayılan 48s, 0 devre dışı) sonrasında doğrulanmamış hesapları siler.
• E-posta değişikliği yeni bir doğrulama akışı başlatır. Kullanıcı oturumu açık kalır; yeni jeton düzenlenir.

Misafir kullanıcılar muaftır — e-postaları yoktur.

Şifre Sıfırlama

Şifre sıfırlama akışı (SMTP gerektirir):

1. POST /api/auth/forgot-password ile {"email": "..."} — sunucu e-postaya sıfırlama bağlantısı gönderir
2. POST /api/auth/reset-password ile {"token": "...", "newPassword": "..."} — yeni şifre belirler

Sıfırlama jetonu TTL’si resetTokenTTLHours (varsayılan 1 saat) tarafından kontrol edilir. Forgot-password uç noktası, auth hız sınırlama kovasını paylaşır.

Soğuma Süresi & Hız Sınırlama

Bedrud dört ayrı hız sınırlama kovası kullanır:

Kova 0 = devre dışı. Tüm limitler uzak IP başınadır. Aşılan istekler 429 Too Many Requests ve Retry-After başlığı döndürür.

Birlikte Çalışabilirlik ve CORS

Bedrud, birden fazla kökenden erişilebilir olacak şekilde tasarlanmıştır; bu, geliştirme (React geliştirme sunucusu) ve üretim (farklı alt alan adları) için kritik öneme sahiptir.

• CORS Politikası: config.yaml içinde tanımlanır. OAuth ve Passkey seremonileri sırasında kullanılan oturum çerezleri için gerekli olan AllowCredentials: true’yu destekler.
• İzin Verilen Kökenler: Varsayılan olarak sunucunun kendi alan adına ve localhost:3000’e (React geliştirme sunucusu portu) izin verir.

Kullanıcı Rolleri (Erişim Kontrolü)

Her kullanıcının aynı anda birden fazla erişim seviyesi içerebilen bir accesses dizisi vardır. JWT claims, middleware’in ayrıntılı izinleri kontrol etmesine olanak tanıyan tam accesses dizisini içerir.

Erişim Seviyeleri

Rol Hiyerarşisi

superadmin > admin > moderator > user > guest

Bir superadmin, oda moderatörü olarak yükseltilmeden herhangi bir odada herhangi bir moderasyon eylemini gerçekleştirebilir. Oda oluşturanlar otomatik olarak oda adminidir ve katılımcıları moderatörlüğe yükseltebilir.

Rol Atama

Roller birden fazla kanal aracılığıyla yönetilir:

• CLI: bedrud user create (user olarak oluşturur), bedrud user promote (superadmin ekler), bedrud user demote (superadmini kaldırır)
• Yönetici Paneli: Kullanıcı detay sayfasında yükselt/düşür düğmeleri bulunur
• Admin API: İstenen accesses dizisi ile PUT /api/admin/users/:id/accesses
• Toplantı İçi: Oda oluşturan, katılımcıları oda seviyesinde moderatörlüğe yükseltebilir

Not: İlk superadmin’i oluşturmak için bir API uç noktası veya web arayüzü yoktur. Kurulumdan sonra, ilk admin erişimini başlatmak için CLI kullanmalısınız (bedrud user create + bedrud user promote). Bu, bilinçli bir güvenlik önlemidir.