JWT, Access ve Refresh Token Nedir?

Selamlar! Bugün projelerin en kritik noktalarından birine, modern web güvenliğinin temel taşına giriyoruz: JWT (JSON Web Token). Bir kullanıcı giriş yaptıktan sonra sistemin onu her defasında nasıl tanıdığını ya da neden sürekli şifre girmek zorunda kalmadığımızı merak ediyorsanız, gelin bu yapıyı teknik detaylarıyla inceleyelim.

Neden JWT Kullanıyoruz?

Eskiden işler biraz daha hantaldı. Session tabanlı sistemlerde, kullanıcı giriş yaptığında sunucu ona bir ID verir ve bu ID’yi kendi hafızasında tutardı. Ama uygulama büyüyüp sunucu sayısı arttığında işler karışmaya başladı. Birinci sunucuda giriş yapan bir kullanıcı, ikinci sunucuya gittiğinde sistem onu tanımıyordu. Sunucuları sürekli senkronize etmek de ciddi bir performans yüküydü.

JWT bu noktada devreye girdi ve "bilgiyi sunucuda tutma, güvenli bir şekilde kullanıcının cebine koy" mantığını getirdi. Bunu bir konser bileti gibi düşünebiliriz. Eskiden kapıdaki görevli isminizi listeden kontrol ederdi (Session). Şimdi ise size üzerinde tüm yetkilerinizin yazdığı, taklit edilemez bir bileklik takıyorlar (JWT). Görevli artık listeye bakmıyor, sadece bilekliğin orijinal olup olmadığını kontrol ediyor.

Access ve Refresh Token Farkı

Sistemde aslında iki farklı anahtarımız var ve ikisinin de görevi çok farklı:

• Access Token: Sizin asıl yetki belgenizdir. API istekleri yaparken "Ben geldim, iznim de bu" dediğiniz karttır. Güvenlik için ömrünü çok kısa tutuyoruz; genelde 15-30 dakika arası. Eğer bir şekilde çalınırsa, kötü niyetli birinin elinde sınırsız süre kalmasın istiyoruz.
• Refresh Token: Bu işin devamlılık tarafıdır. Access Token’ın süresi bittiğinde kullanıcıyı tekrar giriş ekranına atmamak için kullanılır. Ömrü çok daha uzundur; haftalar hatta aylar olabilir. Tek işi, vadesi dolan Access Token yerine yenisini almamızı sağlamaktır.

Büyük Projelerde Gerçek Dünya Senaryosu

Küçük bir blog sitesinde sadece "giriş yaptım mı?" sorusu yeterli olabilir ama büyük ölçekli bir kurumsal projede işler çok daha katmanlı ilerler. Büyük bir projede JWT'nin içine sadece kullanıcı ID'sini değil, "roles" (roller) ve "permissions" (izinler) listelerini de gömeriz.

Gerçek Dünya Örneği: Bir şirketin yönetim panelini düşünün.

• Stajyer: Sadece raporları görüntüleyebilir. (Role: Viewer)

• Editör: İçerik ekleyebilir ve silebilir. (Role: Editor)

• Admin: Kullanıcı silebilir, ödeme altyapısını değiştirebilir. (Role: Admin)

Sunucu veritabanına gidip "Bu adamın silme yetkisi var mı?" diye her saniye sormak yerine, elindeki token'a bakar ve "Tamam, bu kişi bir editör, bu işlemi yapabilir" der. Bu, devasa trafik alan sistemlerde veritabanı yükünü ciddi oranda azaltır.

Sistemin Teknik Akışı

Süreç teknik olarak şöyle ilerliyor: Kullanıcı giriş bilgilerini gönderir, sunucu bunları doğrular ve biri kısa diğeri uzun ömürlü iki tane token üretip geri gönderir. Frontend bu tokenları güvenli bir şekilde saklar. Kullanıcı bir işlem yapmak istediğinde Access Token’ı isteğin başlığına (Header) ekler. Sunucu sadece imzayı kontrol eder ve geçerliyse işlemi yapar.

Access Token’ın süresi dolduğunda sunucu 401 Unauthorized hatası verir. Uygulama bu hatayı aldığı anda arka planda Refresh Token’ı sunucuya gönderir. Sunucu Refresh Token’ın hala geçerli olduğunu doğrularsa yeni bir Access Token üretir. Kullanıcı hiçbir şey fark etmeden uygulamayı kullanmaya devam eder.

Güvenlik ve Depolama Stratejisi

Önemli Güvenlik Uyarısı: Tokenları nerede saklayacağız? Genelde kolaya kaçıp localStorage kullanıyoruz ama bu büyük bir güvenlik açığına davetiye çıkarabilir. Eğer sitenizde bir XSS açığı varsa, kötü niyetli bir JavaScript kodu bu tokenları saniyeler içinde çalabilir.

Bu yüzden, özellikle Refresh Token'ı ve imkan varsa Access Token'ı HttpOnly Cookie içinde tutmak en profesyonel yaklaşımdır:

• HttpOnly: Bu bayrak sayesinde cookie'lere JavaScript ile erişilemez. Saldırgan sitenize sızsa bile token'ı kodla çekip alamaz.
• Secure: Token'ın sadece HTTPS üzerinden gönderilmesini sağlar.
• SameSite: CSRF saldırılarına karşı ek koruma sağlar.

Ayrıca unutmayın; JWT içindeki bilgiler şifreli değil, sadece kodlanmıştır (Base64). İçeriği herkes görebilir, bu yüzden token içine sakın şifre veya hassas veri koymayın.

Sonuç

JWT, hem sunucu yükünü hafifleten hem de kullanıcıya kesintisiz bir deneyim sunan bir standart. Ancak güvenlikten ödün vermemek şartıyla. Tokenları HttpOnly Cookie gibi güvenli alanlarda saklayıp, büyük projelerde rol yönetimiyle birleştirdiğinizde, projeniz hem ölçeklenebilir hem de oldukça güvenli olacaktır.