Access Token ve Refresh Token Mimarisi Nasıl Kurgulanır?

JWT (JSON Web Token) kullanmanın en büyük zorluklarından biri "İptal Edilemez" (Revocation) olmasıdır.

Eski sistemlerde (Session) kullanıcı şifresini değiştirdiğinde veya hesabından "Tüm Cihazlardan Çıkış Yap" dediğinde, sunucu kendi defterindeki (RAM) notu silerdi ve iş biterdi. Ancak JWT sisteminde sunucu defter tutmaz!

Bir hacker kullanıcının token'ını çalarsa, o token'ın üzerindeki SON KULLANMA TARİHİ (Expiration Time) bitene kadar hacker sisteme elini kolunu sallayarak girer. Sunucu "Bu token çalındı, içeri alma" diyemez, çünkü sadece imzaya (Signature) bakar ve imza doğrudur.

---

1. Kısa Ömürlü Access Token (Erişim Jetonu)

Hacker'ın eline geçen token'ın iptal edilememesi çok büyük bir güvenlik açığıdır. Bu yüzden JWT mimarisinde token'ın ömrü (Expiration) çok kısa tutulur. Genellikle 15 dakika veya en fazla 1 saattir.

Kullanıcı sisteme girdiğinde ona bir Access Token (Erişim Jetonu) verilir. Kullanıcı API'ye (Veritabanına) her veri isteyişinde bu token'ı gösterir. Ancak 15 dakika sonra token "Bayatlar" (Expired).

Eğer token hacker'ın eline geçmişse, hacker sadece 15 dakika içeride kalabilir, sonra kapı dışarı edilir.

Peki Kullanıcı Deneyimi Ne Olacak?

Kullanıcının her 15 dakikada bir yeniden Kullanıcı Adı ve Şifre girmesini isteyemezsiniz. Kullanıcı isyan eder ve uygulamayı siler. İşte tam burada sahneye ikinci aktör çıkar.

2. Uzun Ömürlü Refresh Token (Yenileme Jetonu)

Kullanıcı giriş yaptığında sunucu ona 1 değil, tam 2 adet token verir:

1. Access Token: Ömrü 15 Dakikadır. API kapılarını açar.
2. Refresh Token: Ömrü uzundur (7 Gün veya 30 Gün). API kapılarını AÇAMAZ. Tek bir görevi vardır: Yeni bir Access Token almak.

Sistem şöyle çalışır:

1. Kullanıcı 14 dakika boyunca Access Token ile içeride rahatça dolaşır.
2. 16. dakikada bir sayfaya tıklar. Sunucu "Senin Access Token'ın süresi dolmuş (Expired)" der ve 401 Unauthorized hatası verir.
3. Frontend uygulaması (React/Vue) kullanıcıya "Şifreni gir" EKRANINI GÖSTERMEDEN, arka planda gizlice Auth sunucusuna gider ve Refresh Token'ı gösterir.
4. Sunucu Refresh Token'ı alır, veritabanından (Evet, Refresh tokenlar veritabanında tutulur ve iptal edilebilirler) kontrol eder. "Tamam, bu kişi hala yetkili, al sana yeni bir 15 dakikalık Access Token" der.
5. Frontend uygulaması yeni Access Token'ı alır ve kullanıcının 16. dakikada tıkladığı sayfayı açar.

Kullanıcı tüm bu arka plan savaşlarının ruhu bile duymaz, sistemden hiç çıkış yapmadığını sanır.

Kendi tasarladığınız veya kullandığınız Access Token'ların içindeki o kritik "exp" (Expiration Time - Bitiş Süresi) bilgisini (Unix Timestamp olarak bulunur) okumak ve insan dilindeki tarihe çevirmek için JWT Decoder aracımızı kullanın. Sistemin tüm yapı taşları için JWT ve API Kimlik Doğrulama Rehberimizi incelemeyi ihmal etmeyin.

---

🕸️ Knowledge Graph & Semantik Bağlantılar

Bu içerik, Intent.com.tr'nin Siber Güvenlik topikal kümesinin (Topic Cluster) bir parçasıdır. Konuyu daha derinlemesine anlamak için aşağıdaki varlıkları (Entities) ve ilişkili içerikleri inceleyebilirsiniz:

📖 İlgili Rehberler ve İçerikler

• Kaba Kuvvet (Brute-Force) Saldırılarına Karşı Parola Güvenliği
• JWT Token Güvenliği: İmza Doğrulama ve XSS Koruması
• Rastgelelik (Entropy) ve Güvenli Şifreleme Algoritmaları

🧠 Semantic Entities (Terimler & Senaryolar)

• Kavram: Information Gain (Bilgi Kazanımı)
• Kavram: Canonical Tag (Rel=Canonical)
• Uygulama: E-Ticaret Sitelerinde Altyapı Taşıma (Migration)

Semantic Yönerge: Bu sayfa Access Token ve Refresh Token Mimarisi Nasıl Kurgulanır? konusundaki kullanıcı niyetini (Search Intent) karşılamak üzere yapılandırılmıştır.