Süresi Dolmuş JWT Token'ı Çöz: Token Süresini Kontrol Et

Süresi Dolmuş JWT Token’ını Çözme

Süresi dolmuş bir JWT’yi çözmek, geçerli bir token ile aynı payload’ı ortaya çıkarır. Token yapısı değişmez; exp claim’i yalnızca geçmişte bir Unix zamanı içerir. Bu, kimlik doğrulama hatalarını ayıklamak, hangi claim’lerin verildiğini kontrol etmek ve bir token’ın ne zaman dolduğunu sunucu loglarına erişmeden anlamak için kullanışlıdır.

Çözülmüş Token

Bu örnekteki token şu şekilde çözülür:

{
  "header": {
    "alg": "HS256",
    "typ": "JWT"
  },
  "payload": {
    "sub": "1234567890",
    "name": "Alice",
    "iat": 1600000000,
    "exp": 1600003600,
    "iss": "auth.example.com",
    "aud": "api.example.com"
  }
}

iat değeri 1600000000 (13 Eylül 2020, 12:26:40 UTC). exp değeri 1600003600, tam olarak bir saat sonra. Her ikisi de saniye cinsinden Unix zamanlarıdır. Bu token Eylül 2020’de süresi dolmuştur.

Zaman Claim’leri ve Anlamları

iat (issued at)

Token’ın verildiği Unix zamanı. Bir anahtar döndürmeden veya kullanıcının şifresi değiştirilmeden önce verilen token’ları tespit etmek için kullanılır. Bazı sistemler, teknik olarak süresi dolmamış olsa bile, kullanıcının son şifre değişikliğinden önceki bir iat değerine sahip token’ları reddeder.

exp (expires at)

Token’ın reddedilmesi gereken Unix zamanı. Sunucular current_time > exp kontrolü yapar ve doğruysa 401 döndürür. Kontrol katıdır: exp == current_time olan bir token çoğu uygulama tarafından zaten süresi dolmuş olarak kabul edilir.

nbf (not before)

Daha az yaygın. Token’ın kabul edilmemesi gereken Unix zamanı. Gelecekte kullanılması amaçlanan bir token verdiğinizde veya verilişten sonra token’ın aktif hale gelmesi için bir bekleme süresi istediğinizde kullanışlıdır.

Üçü arasındaki ilişki

issued at (iat) --> valid from (nbf) --> valid until (exp)

Pratikte iat ve nbf genellikle aynı değerdir veya nbf atlanır. Çoğu uygulama için kritik çift iat ve exp’dir.

Token Yenileme Akışı

Bir access token’ın süresi dolduğunda, istemci şunları yapmalıdır:

1. 401 yanıtını tespit etme (veya istekten önce istemci tarafında süre sonunu kontrol etme)
2. Refresh token’ı token uç noktasına gönderme (POST /oauth/token veya benzeri)
3. Yeni bir access token (ve bazen yeni bir refresh token) alma
4. Orijinal isteği yeni access token ile yeniden deneme
5. Refresh token’ın da süresi dolmuşsa, kullanıcıyı giriş akışına yönlendirme

İyi uygulanmış bir istemci kütüphanesi, 1’den 4’e kadar olan adımları şeffaf bir şekilde yönetir. Kullanıcılar, refresh token’larının da süresi dolmadığı sürece süre sonu hatalarını asla görmez.

async function fetchWithRefresh(url, options) {
  let response = await fetch(url, {
    ...options,
    headers: { Authorization: `Bearer ${getAccessToken()}` }
  });

  if (response.status === 401) {
    await refreshAccessToken();
    response = await fetch(url, {
      ...options,
      headers: { Authorization: `Bearer ${getAccessToken()}` }
    });
  }

  return response;
}

Saat Kayması (Clock Skew)

JWT süre sonu, exp claim’ini sunucunun geçerli saatiyle karşılaştırır. Token’ı veren sunucu ile doğrulayan sunucunun saatleri birkaç saniyeden fazla farklıysa, geçerli token’lar hemen reddedilebilir.

Standart tolerans 5 dakikalık bir paydır (exp + 300 > current_time). Çoğu JWT kütüphanesi, yapılandırılabilir bir saat kayması toleransını destekler. Üretim sistemleri, sunucu saatlerini birbirlerinin birkaç saniyesi içinde tutmak için NTP veya benzer bir zaman senkronizasyon protokolü çalıştırmalıdır.

Yaygın Hata Ayıklama Senaryoları

Token veriliş ile ilk kullanım arasında süresi doldu

İstemci bir token aldı ancak hemen kullanmadı. Bu, toplu işlerde, kuyruklanmış görevlerde veya agresif önbelleğe alma kullanan istemcilerde olur. Access token ömrünüz 1 saatse ve bir arka plan işi çalıştırılmadan önce 90 dakika kuyrukta beklerse, token’ının süresi ilk kullanımda dolmuş olur. Çözümler: istekten hemen önce yeni bir token alın veya arka plan işleri için daha uzun ömürlü token’lara sahip bir servis hesabı kullanın.

Sunucu saat kayması

Veren sunucunun saati, doğrulayan sunucunun saatinden ileridedir. T zamanında verilen 5 dakikalık süre sonu olan bir token, verenin saatine göre T+5 dakikaya kadar geçerlidir. Doğrulayıcının saati 10 dakika gerideyse, token’ı T+5d+10d’ye kadar geçerli görür. Doğrulayıcının saati 10 dakika ilerideyse, token’ı verilişten hemen sonra reddeder. JWT veren veya doğrulayan tüm sunucularda saat kaymasını izleyin.

Saat dilimi karışıklığı

exp ve iat claim’leri her zaman UTC saniye cinsinden Unix zamanlarıdır. Biçimlendirilmiş tarih stringleri değildirler. Karışıklık, geliştiriciler bu değerleri loglarken ve yerel saat olarak yorumladıklarında veya UTC epoch yerine yerel saati kullanarak manuel olarak JWT oluşturduklarında ortaya çıkar. Bir exp değerini okunabilir zamana dönüştürmek için: JavaScript’te new Date(exp * 1000).toISOString(), Python’da datetime.fromtimestamp(exp, tz=timezone.utc).

Token çözücü ile hata ayıklama

Süresi dolmuş bile olsa herhangi bir JWT’yi yapıştırın ve tam exp değerini görün. Bunu insan tarafından okunabilir bir tarihe dönüştürmek için Unix zamanı dönüştürücüyü kullanın. Token’ın amaçlanan ömrünü görmek için iat ile ve ne kadar önce süresinin dolduğunu görmek için geçerli zamanla karşılaştırın.