- Konu sahibi
- #1
Refresh token rotasyonu, her başarılı yenileme isteğinde eski refresh token’ı geçersiz kılıp yerine yeni bir refresh token verme yöntemidir. Böylece ele geçirilmiş bir refresh token tekrar kullanılırsa sunucu bu kullanımı fark edebilir; ilgili oturum veya token ailesi iptal edilerek saldırganın sürekli yeni access token üretmesi engellenir. Ancak rotasyon, token çalınmadan önceki riski ortadan kaldırmaz ve tek başına oturum güvenliğinin tamamı değildir.
İlk oturum açmada istemciye bir access token ve bir refresh token verilir. Access token süresi dolduğunda istemci refresh token’ı sunucuya gönderir. Sunucu token’ın geçerli olduğunu ve daha önce kullanılmadığını kontrol eder, eski token’ı tüketilmiş olarak işaretler ve yeni bir access token ile yeni bir refresh token üretir.
Sunucu eski refresh token’ın tekrar kullanıldığını görürse bu durum token replay olarak değerlendirilir. Replay tespitinde yalnızca zaten tüketilmiş eski tokenı reddetmek yeterli değildir. Meşru istemci ile saldırganı ayırt edemeyen sunucu, ilgili yetkilendirme ailesinin etkin refresh tokenını da iptal ederek zinciri keser; kullanıcının yeniden yetkilendirme yapması gerekir. Bu, RFC 9700’daki rotasyonla replay tespiti akışının kritik parçasıdır.
Önemli nokta şudur: Saldırgan çalınmış tokenı meşru istemciden önce kullanırsa saldırgan yeni token alabilir. Rotasyonun asıl avantajı, aynı eski token daha sonra tekrar kullanıldığında bu anormalliğin tespit edilebilmesidir.
Bir kullanıcı giriş yaptığında R1 refresh token’ı verilsin. İstemci R1 ile yenileme yaptığında sunucu R1’i geçersiz kılar ve R2’yi üretir. İstemci artık yalnızca R2’yi kullanmalıdır. Bir saldırgan daha sonra R1’i gönderirse istek reddedilir ve sunucu aynı yetkilendirme ailesinin etkin R2 tokenını da iptal eder. Meşru istemci artık R2 ile devam edemez; yeniden giriş/yetkilendirme gerekir.
Rotasyonun davranışı, tokenın durumuna ve alınacak karara göre değişir:
Bu akışta en sık yapılan hata, yalnızca yeni token üretip eski tokenı geçersiz kılmamaktır. Böyle bir uygulama rotasyon görünümünde olsa da eski token tekrar tekrar kullanılabilir. İkinci hata, eşzamanlı istekleri hiç hesaba katmamaktır; aynı tokenı kullanan iki normal istekten biri gereksiz yere saldırı gibi yorumlanabilir. Bu nedenle atomiklik, istemci yenileme kuyruğu ve cihazlar arası oturum politikanız birlikte tasarlanmalıdır.
Refresh tokenı tarayıcıda erişilebilir JavaScript depolamasında tutmak, XSS etkisini büyütebilir. Saklama yöntemi seçilirken uygulamanın istemci mimarisi, çerez politikaları, CSRF önlemleri ve oturum iptal gereksinimleri birlikte değerlendirilmelidir. Access token ve refresh token için aynı süreyi veya aynı kullanım politikasını zorunlu kabul etmeyin; refresh token daha güçlü koruma ve ayrı iptal takibi gerektirir.
Public OAuth istemcilerinde replay tespiti için RFC 9700, refresh tokenların gönderene bağlanmasını veya rotasyon kullanılmasını ister. İstemcinin confidential/public olması ve sağlayıcının desteklediği mekanizma önemlidir. Tokenlar TLS ile taşınmalı; scope ve yetkilendirilmiş kaynak ilişkisi korunmalı, boşta kalma süresi ve sonlandırma politikası belirlenmelidir.
Nasıl çalışır?
İlk oturum açmada istemciye bir access token ve bir refresh token verilir. Access token süresi dolduğunda istemci refresh token’ı sunucuya gönderir. Sunucu token’ın geçerli olduğunu ve daha önce kullanılmadığını kontrol eder, eski token’ı tüketilmiş olarak işaretler ve yeni bir access token ile yeni bir refresh token üretir.
Sunucu eski refresh token’ın tekrar kullanıldığını görürse bu durum token replay olarak değerlendirilir. Replay tespitinde yalnızca zaten tüketilmiş eski tokenı reddetmek yeterli değildir. Meşru istemci ile saldırganı ayırt edemeyen sunucu, ilgili yetkilendirme ailesinin etkin refresh tokenını da iptal ederek zinciri keser; kullanıcının yeniden yetkilendirme yapması gerekir. Bu, RFC 9700’daki rotasyonla replay tespiti akışının kritik parçasıdır.
Önemli nokta şudur: Saldırgan çalınmış tokenı meşru istemciden önce kullanırsa saldırgan yeni token alabilir. Rotasyonun asıl avantajı, aynı eski token daha sonra tekrar kullanıldığında bu anormalliğin tespit edilebilmesidir.
Somut örnek
Bir kullanıcı giriş yaptığında R1 refresh token’ı verilsin. İstemci R1 ile yenileme yaptığında sunucu R1’i geçersiz kılar ve R2’yi üretir. İstemci artık yalnızca R2’yi kullanmalıdır. Bir saldırgan daha sonra R1’i gönderirse istek reddedilir ve sunucu aynı yetkilendirme ailesinin etkin R2 tokenını da iptal eder. Meşru istemci artık R2 ile devam edemez; yeniden giriş/yetkilendirme gerekir.
Uygulanabilir tasarım ve işlem adımları
- Her refresh token için benzersiz bir kimlik, bağlı kullanıcı veya oturum kimliği, önceki token ilişkisi, oluşturulma durumu ve iptal durumu tutun. Veritabanında tokenın kendisini açık biçimde saklamak yerine doğrulama için güçlü bir özet değer saklamak tercih edilir.
- Yenileme isteğinde tokenı doğrulayın; süresi dolmuş, iptal edilmiş veya daha önce kullanılmış tokenı yeni token üretmeden reddedin.
- Başarılı yenileme sırasında eski tokenı tüketilmiş olarak işaretleyip yeni tokenı aynı oturum ailesine bağlayın. Eski tokenın iptali ve yeni tokenın oluşturulması tek atomik işlem gibi ele alınmalıdır.
- Yanıt olarak yeni access token ile yeni refresh token gönderin. İstemci, eski refresh tokenı güvenilir biçimde silip yalnızca yenisini kullanmalıdır.
- Daha önce tüketilmiş bir refresh token yeniden gelirse token değerini günlüğe yazmadan olayı kaydedin ve bağlı yetkilendirme ailesinin etkin refresh tokenını iptal edin. Yalnızca eski tokenı reddedip yenisini açık bırakmayın.
- Birden fazla sekme veya cihazın aynı anda yenileme yapabileceğini test edin. İstem dışı yarışlar yanlışlıkla oturum kapatıyorsa istemci tarafında tekil yenileme kuyruğu veya sunucuda açıkça tanımlanmış kısa bir eşzamanlılık politikası kullanın.
Karar verirken dikkat edilecek noktalar
Rotasyonun davranışı, tokenın durumuna ve alınacak karara göre değişir:
| Durum | Sunucu davranışı | İstemci sonucu |
|---|---|---|
| Geçerli ve ilk kez kullanılan token | Eski tokenı tüket, yeni çift üret | Yeni tokenlarla devam eder |
| Süresi dolmuş veya iptal edilmiş token | Yenilemeyi reddet | Yeniden giriş gerekebilir |
| Daha önce kullanılmış token | İsteği reddet, bağlı etkin refresh zincirini iptal et ve olayı incele | Bu yetkilendirme için yeniden giriş gerekir |
Bu akışta en sık yapılan hata, yalnızca yeni token üretip eski tokenı geçersiz kılmamaktır. Böyle bir uygulama rotasyon görünümünde olsa da eski token tekrar tekrar kullanılabilir. İkinci hata, eşzamanlı istekleri hiç hesaba katmamaktır; aynı tokenı kullanan iki normal istekten biri gereksiz yere saldırı gibi yorumlanabilir. Bu nedenle atomiklik, istemci yenileme kuyruğu ve cihazlar arası oturum politikanız birlikte tasarlanmalıdır.
Refresh tokenı tarayıcıda erişilebilir JavaScript depolamasında tutmak, XSS etkisini büyütebilir. Saklama yöntemi seçilirken uygulamanın istemci mimarisi, çerez politikaları, CSRF önlemleri ve oturum iptal gereksinimleri birlikte değerlendirilmelidir. Access token ve refresh token için aynı süreyi veya aynı kullanım politikasını zorunlu kabul etmeyin; refresh token daha güçlü koruma ve ayrı iptal takibi gerektirir.
Public OAuth istemcilerinde replay tespiti için RFC 9700, refresh tokenların gönderene bağlanmasını veya rotasyon kullanılmasını ister. İstemcinin confidential/public olması ve sağlayıcının desteklediği mekanizma önemlidir. Tokenlar TLS ile taşınmalı; scope ve yetkilendirilmiş kaynak ilişkisi korunmalı, boşta kalma süresi ve sonlandırma politikası belirlenmelidir.
