Neden hem bir access token'a hem de bir refresh token'a ihtiyacın var?

Question

IT Interview Practice · Accepted Answer

İki token, doğrudan bir çelişkiyi çözmek için vardır: bir access token **her request'te gönderilmelidir** (yani çokça açığa çıkar), ama aynı zamanda sık girişleri zorlamadan **uzun süren** oturumlar da istersin. İkisine birden tek bir token'da güvenle sahip olamazsın — bu yüzden işi bölersin.

## İki rol

- **Access token** — kısa ömürlü (tipik olarak 5–15 dakika), her API çağrısında `Authorization` header'ında gönderilir. Sürekli iletildiği için bir sızıntı olasıdır; kısa tutmak, çalınan birinin neredeyse anında sona ermesi demektir.
- **Refresh token** — uzun ömürlü (günler/haftalar), yeni access token'lar elde etmek için **yalnızca** auth sunucusunun token endpoint'ine gönderilir. Nadiren dolaşır, daha güvenli saklanabilir ve sunucu tarafında iptal edilebilir.

```
Login ──▶ access (15m) + refresh (30d)
Her API çağrısı ──▶ access gönder
Access süresi doldu ──▶ refresh gönder ──▶ yeni access (+ döndürülmüş refresh)
```

## Neden tek bir token değil?

| | Tek uzun ömürlü access token | Access + refresh |
|---|---|---|
| Açığa çıkma | Her request'te gönderilir, uzun yaşar → büyük hırsızlık penceresi | Access kısa ömürlü; refresh nadiren gönderilir |
| İptal | Zor (stateless JWT geri alınamaz) | refresh token'ı iptal et; access dakikalar içinde ölür |
| UX | Kısaysa sık sık yeniden giriş | Kimlik bilgilerini yeniden girmeden oturumda kalır |
| Sızıntının etki alanı | Büyük | Küçük (access hızla sona erer) |

- **Tek kısa access token, refresh yok** → güvenli, ama kullanıcı birkaç dakikada bir çıkış yapar. Berbat UX.
- **Tek uzun access token** → harika UX, ama sızan bir token uzun süre geçerlidir ve kolayca iptal edilemez.
- **Access + refresh** → kısa açığa çıkma penceresi *ve* uzun oturumlar. Refresh token tek uzun ömürlü sırdır ve tek bir güvenli yerde yaşar.

## Bölünme neyi mümkün kılar

- **Stateless access token'lara rağmen iptal.** Bir JWT access token'ı süresi dolmadan geçersiz kılamazsın, ama refresh token'ı *silebilir/reddedebilirsin*, böylece oturum bir sonraki refresh'te (dakikalar içinde) biter.
- **Refresh token rotation** — her kullanımda yeni bir refresh token ver ve eskisinin (kullanılmış) yeniden kullanımını tespit et (hırsızlık işareti), ardından tüm zinciri iptal et.
- **En az açığa çıkma** — uzun ömürlü sır (refresh) tam olarak tek bir endpoint'e gönderilir, ideal olarak XSS'in erişemeyeceği bir `httpOnly` cookie'de saklanır.

## Neden önemli

Bu, modern standart auth tasarımıdır ve görüşmeciler bunu, sadece *nasıl*'ı değil *neden*'i anlayıp anlamadığını görmek için sorar. Kilit içgörü ödünleşimdir: statelessness ve kısa açığa çıkma (access) ile uzun oturumlar ve iptal edilebilirlik (refresh) arasında. Yanlış yapmak — uzun ömürlü bir access token, rotation yok, `localStorage`'da saklanan refresh — sızan tek bir token'ı uzun ömürlü bir hesap ihlaline dönüştürür. Bölünmeyi ve her token'ın sana ne kazandırdığını adlandırmak, güvenlik bilincine sahip bir mühendisten bilmesi beklenen şeydir.

	Tek uzun ömürlü access token	Access + refresh
Açığa çıkma	Her request'te gönderilir, uzun yaşar → büyük hırsızlık penceresi	Access kısa ömürlü; refresh nadiren gönderilir
İptal	Zor (stateless JWT geri alınamaz)	refresh token'ı iptal et; access dakikalar içinde ölür
UX	Kısaysa sık sık yeniden giriş	Kimlik bilgilerini yeniden girmeden oturumda kalır
Sızıntının etki alanı	Büyük	Küçük (access hızla sona erer)

İki rol

Neden tek bir token değil?

Bölünme neyi mümkün kılar

Neden önemli

İlgili sorular