token based authentication kullaniyorsaniz Cross-Site Request Forgery (CSRF) veya Cross-site scripting (XSS) gibi saldirilarda yapacak pek birsey yok,
24 saat bir token icin cok uzun bir sure,
token bazli authentication yapan sistemler soyle yapiyor
iki adet token oluyor,
- kisa omurlu (5,10 dk) veya tek kullanimlik access token, - calinsa bile, ya islevini yitirmis yada kullanilmis olacak
- uzun omurlu (1hafta, 1 ay) refresh token,
access token claim tutuyor kullanici bilgisi vs,
refresh token ise kullanici ile iliskilendirilmis random bir veri tutar, kullanildiginda invalidate edilir.
seneryo 1 kisa omurlu access token
- kullanicinin kimligi refresh tokenin omru bitene kadar dogrulanabilir
- access tokenin omru bitmis ise kullanici refresh token ile istek atip yeni access token ister, cevap olarak yeni access ve refresh token gonderirsin, bu sekilde dongu devam eder
seneryo 2 tek kullanimlik access token
- kullanici her istek attiginda tokeni invalidate edersin ve yenisini yollarsin,
- tokeni kullanmadan omru bitmis ise ustteki adimlar ayni
gelelim token guvenligine
CSRF
buna yapilabilcek pek birsey yok, session bazli sitemlerdede bu sekilde
XSS
bunda öncelikli olarak tekeni güvenli biryerde tutman lazım, kesinlikle local storage da filan tutma, xss saldırılarına karsi cok korunaksiz
session storage
local storage ile ayni kaderi paylaşıyor
http only cookie
token saklamak için güzel bir yer, client side javascript ile erişilemiyor
in memory
buda mantikli bir secenek değil.
yapılabilecek diğer şeyler
- tokeni tuttuğun cookienin adi anlamsız saçma biseyler olabilir
- tokeni parçalayıp birden fazla cookiede tutabilirsin. tokenin bir kismi çalınsa bile kullanılamaz olacak,
- kriptografi, rsa aes gibi algoritmalarla tokeni kriptolayabilirsin.
edit: ornek olarak jwt kullandigim bir projemin linki https://github.com/stellayazilim/stella.backend/tree/main/src/modules/auth
