Kimliği tek bir sistem sahiplensin
Giriş formu bir istek toplar. Kimlik doğrulama sistemi, bu isteğin bir kimlik kurup kurmadığına karar verir ve uygulamanın geri kalanının güvendiği oturumu düzenler. Bu sorumluluğu tek bir yerde tutmak, her rotanın giriş yapmış kullanıcının kendi yorumunu icat etmesini önler.
supastack, kimlik ve oturum yönetimi için Better Auth'u kullanır. Uygulama kodu, korunan sınırlarda oturumu çözer ve onu bir çalışma alanına bağlar. Arayüz faydalı erişim durumları gösterebilir ama istemci durumu, bir işlemin yetkili olduğunun kanıtı olmamalıdır.
Kural, ürünün sunduğu her yüzeyde geçerli olmalıdır. Web, mobil ve masaüstü istemciler aynı kimlik kararını üç kez uygulamak yerine tüketmelidir — “giriş yapmış”ın üç yorumu, hesap hatalarının geldiği yerdir.
Giriş yöntemlerini bilinçli seçin
Her yöntem, sürtünmeyi saldırı yüzeyi ve dış bağımlılıkla takas eder. Parolalar sıfırlama akışları ve hız sınırlaması ister. Sihirli bağlantılar ve tek kullanımlık kodlar e-posta teslimatına bağlıdır. OAuth, kimliği Google, GitHub ya da Apple gibi sağlayıcılara devreder — ve onların kesintilerini, izin ekranlarını ve geri çağrı kurallarını miras alır.
supastack bunları Better Auth üzerinden tek bir kimlik kararının arkasında birleştirir — e-posta OTP, parola, sihirli bağlantı, OAuth; iki faktör ve passkey'ler de mevcut. Hedef kitlenizin gerçekten ihtiyaç duyduğu en küçük kümeyi sunun; her ek yöntem başka bir geri çağrı yolu, başka bir hata modu ve lansmandan önce doğrulanacak başka bir akıştır. Kimlik doğrulama kılavuzu bağlantıyı kapsar.
Bir kişi birden fazla yolla giriş yapabildiğinde, yöntemlerin nasıl birleşeceğine karar verin. Aynı adrese çözülen bir Google hesabı ve bir e-posta sihirli bağlantısı iki değil, tek bir kimliğe inmelidir. Hesap bağlama kuralları kimlik kararının parçasıdır ve onları yanlış yapmak, aylar sonra gizemli kayıp veri olarak ortaya çıkan yinelenen kullanıcılar yaratır.
Oturumlar asıl kimlik bilgisidir
Girişten sonra her isteğin taşıdığı parola değil, oturumdur. Süresi, saklanması ve geçersiz kılma kuralları gerçek güvenlik duruşunu tanımlar. Çıkıştan sağ çıkan ya da çıkarılmış bir çalışma alanı üyesinin kullanmaya devam edebildiği bir oturum, hiçbir cilalı giriş ekranının düzeltemeyeceği bir kimlik doğrulama hatasıdır.
Yaşam döngüsüne baştan karar verin: oturumlar ne kadar yaşar, kullanıcılar etkin oturumlarını görüp iptal edebilir mi ve parola değişikliği, e-posta değişikliği ya da çalışma alanından çıkarılma onlara ne yapar. Oturum yönetimi kitte tam da bu yüzden bir modül olarak vardır; bu kararlar ertelemesi kolay, sonradan eklemesi pahalıdır.
Oturumu istenen kayda bağlayın
Giriş yapmış olmak her kayda erişim vermez. Kullanıcının çalışma alanını sunucuda çözün ve bu kapsamı okuma ve yazma işlemlerine dahil edin. Bir görev tanımlayıcısı ya da kurtarma bağlantısı işe bir referanstır; onu alma izni değildir — çalışma alanı sınırları yazısı sınırın bu tarafını ayrıntılı anlatır.
Kapsamı sabit bir sırayla çözün: oturumu doğrulayın, üyeliği yükleyin, ardından o çalışma alanı bağlamıyla okuyun ya da yazın — asla tersi yönde değil. Middleware anonim bir ziyaretçiyi yönlendirebilir ama işlemi yetkilendiremez; kontrol, kaydın dokunulduğu sunucu eyleminde ya da rota işleyicisinde olmalıdır.
Hesapların yalnızca başlangıcı değil, yaşam döngüsü vardır
Sağlama, bu sınırın ilk testidir. Bir kullanıcı kaydolduğunda, ardından gelen çalışma alanı ve sahiplik kayıtları birden fazla kez oluşturulmaya karşı güvenli olmalıdır — yaşam döngüsü kancaları sağlayıcılar, yeniden denemeler ya da destek araçları tarafından yeniden oynatılabilir. Yinelenen bir olay yinelenen bir organizasyon değil, işlemsizlik olmalıdır.
Yaşam döngüsünün sonu da aynı özeni hak eder. E-posta değişiklikleri, parola sıfırlamaları, üye çıkarma, hesap silme ve veri dışa aktarma, her biri kendi kötüye kullanım durumları olan küçük akışlardır — iki kez çalışan bir sıfırlama bağlantısı, ekip arkadaşının kayıtlarını sızdıran bir dışa aktarma. supastack tam da bu yüzden GDPR dışa aktarma ve oturum yönetimiyle gelir; neyin üzerine inşa ederseniz edin, sıkıcı akışlara bütçe ayırın.
Sonu dahil tüm yaşam döngüsünü test edin
Başarılı bir giriş testi faydalı ama eksiktir. Geçersiz kimlik bilgilerini, süresi dolmuş ya da yeniden kullanılmış doğrulama kodlarını, anonim istekleri ve çalışma alanları arası erişimi uygulayın. Çıkışın oturumu geçersiz kıldığını ve dönen bir istemcinin daha önce yetkilendirilmiş bir ekranı korunan iş için kullanamayacağını doğrulayın.
İşleyici testlerini dağıtım kabulünden ayırın. Bellek bağdaştırıcısı, Postgres kalıcılığını ya da sağlayıcı geri çağrısını kanıtlamadan gerçek bir kimlik doğrulama işleyicisinin semantiğini kurabilir. Tam giriş yolculuğunun çalıştığını iddia etmeden önce yapılandırılmış kaynağı, geri çağrı yolunu, oturum geri yüklemeyi ve çıkışı dağıtılmış bağımlılıklarla doğrulayın.
- Geçersiz kimlik bilgileri ve süresi dolmuş ya da yeniden kullanılmış doğrulama kodları reddedilir.
- Anonim ve çalışma alanları arası istekler sahiplenilmiş veri alamaz.
- Çıkış oturumu geçersiz kılar — bayat bir istemci hareket etmeye devam edemez.
- Sağlanan kayıtlar, yaşam döngüsü kancaları yeniden oynatıldığında idempotent kalır.
- Gerçek sağlayıcı geri çağrıları yapılandırılmış kaynakta çalışır — varsayılmış değil, doğrulanmış.
Sık sorulan kimlik doğrulama soruları
Aşağıdaki sorular, giriş formu bittiğinde ve sistemin çalışmaya devam etmesi gerektiğinde ortaya çıkar.
- Rotaları korumak için middleware yeterli mi? — Middleware kullanışlı bir yönlendirmedir, yetkilendirme katmanı değildir. Her sunucu eylemi ve rotası oturumu ve çalışma alanını kendisi çözer; sayfa düzeyi korumalar işlemleri yetkilendirmeden ekranları gizler.
- Auth'u kendim mi yapmalıyım, kütüphane mi kullanmalıyım? — Oturum semantiği nadiren bir SaaS'in farklılaştığı yerdir. Net modül sınırları arkasında Better Auth gibi bakımlı bir kütüphane, önemli kararları — kapsam, yaşam döngüsü — kodunuzda tutarken test edilmiş primitifler verir.
- Oturumlar çalışma alanlarıyla nasıl ilişkilidir? — Oturum kişiyi tanımlar; çalışma alanı dokunabilecekleri kayıtları tanımlar. Her istek için üyeliği sunucuda çözün ve istemcinin gönderdiği çalışma alanı kimliğine asla güvenmeyin.
- B2B müşteriler kimlik doğrulamadan ne bekler? — Rolleri olan ekip çalışma alanları, OAuth girişi, oturum görünürlüğü ve iptali ve bir denetim izi. İki faktör ve passkey'ler yönetici rolleri için giderek beklenen hale geliyor.
- Üretimde kimlik doğrulamayı ne bozar? — Genellikle kenarlar: yalnızca yerelde var olan bir geri çağrı URL'si, iki kez sağlayan bir kanca, üyelikten uzun yaşayan bir oturum. Akışların yalnızca başlangıçlarını değil, sonlarını test edin.