JWT Son Kullanma ve Düzenleme Tarihi Talepleri: Unix Zaman Damgaları Token Kimlik Doğrulamasını Nasıl Güçlendiriyor

Bir kullanıcı SaaS uygulamasına her giriş yaptığında, tarayıcısına ya da mobil uygulamasına bir auth token üretilip iletilir. Bu token'ın içinde sessiz bir saat işler. Düz bir Unix timestamp olarak saklanan JWT expiration alanı, token'ı okuyan her sunucuya bu kimlik bilgisine ne zaman güvenmeyi bırakması gerektiğini tam olarak söyler. Bu timestamp'i birkaç saniyelik bir hatayla bile ayarlarsan, kullanıcılar ya çok erken oturumdan atılır ya da daha kötüsü, güvenlik politikanın izin verdiğinden çok daha uzun süre geçerli bir oturumu taşır. Özellikle exp ve iat olmak üzere JSON web token claim'lerinin nasıl çalıştığını anlamak, bir SaaS ekibinin kimlik doğrulamayı sürtünme eklemeden sıkılaştırmak için yapabileceği en pratik şeylerden biridir.

JWT Nedir ve Timestamp'ler Neden İçinde Bulunur

Bir JSON web token , nokta karakteriyle ayrılmış üç Base64 kodlu bölümden oluşan kompakt ve URL-güvenli bir kimlik bilgisidir: header, payload ve signature. Zamana duyarlı veriler payload bölümünde yer alır. JWT'ler stateless olduğundan, sunucu doğrulama için bir veritabanında oturum aramaz. Bunun yerine payload'a gömülü claim'leri okur ve kriptografik imzaya güvenir. Bu tasarım hızlı ve ölçeklenebilirdir; ancak gerçek bir kısıtlama getirir: bir token bir kez üretildi mi, sunucu onu "silemez". Token'ın ömrünü sınırlamanın tek güvenilir yolu, doğrudan token içine bir son kullanma timestamp'i gömmektir.

Bu nedenle zaman, özellikle Unix epoch zamanı, JWT güvenliğinin merkezinde yer alır. RFC 7519 spesifikasyonu, JWT'leri tanımlarken zamanla ilgili claim'lerin "NumericDate" değerleri olarak ifade edilmesini zorunlu kılar. Bu değerler, 1 Ocak 1970 UTC'den bu yana geçen saniye sayısından ibarettir. Saat dilimi yok, yerel biçimlendirme yok. Dünyanın herhangi bir yerindeki herhangi bir sunucunun kendi saatiyle karşılaştırabileceği bir integer.

exp ve iat Claim'leri Açıklandı

JWT spesifikasyonu birkaç kayıtlı claim tanımlar. Token yaşam döngüsü yönetimi açısından en önemli ikisi şunlardır:

• exp (Expiration Time - Son Kullanma Zamanı): Token'ın artık kabul edilmemesi gereken timestamp. Sunucuların, mevcut zamanın bu değere eşit ya da daha büyük olduğu her token'ı reddetmesi zorunludur. Bu, JWT expiration mekanizmasının temel yapı taşıdır.
• iat (Issued At - Yayınlanma Zamanı): Token'ın oluşturulduğu andaki timestamp. iat claim'i varsayılan olarak zorunlu tutulmaz; ancak son derece kullanışlıdır. Token'ın ne kadar eski olduğunu hesaplamana, exp 'den bağımsız olarak maksimum yaş politikası uygulamanı ve geçmişte şüphe uyandıracak kadar erken üretilmiş token'ları tespit etmeni sağlar.

Üçüncü bir claim olan nbf (Not Before - Bu Zamandan Önce Değil), bir token'ın geçerli olduğu en erken zamanı tanımlar. Daha az yaygın kullanılır, ancak aynı Unix timestamp formatını izler.

Bu üç değerin tamamı integer'dır. Sistemin onları milisaniye cinsinden üretiyorsa (JavaScript'in Date.now() fonksiyonu kullanıldığında sık yapılan bir hata), ortaya çıkan sayı beklenenden yaklaşık 1.000 kat büyük olur. Mevcut epoch saniyesiyle exp 'yi karşılaştıran bir sunucu, token'ın 33.658 yılında sona ereceğini görür ve onu hiçbir zaman reddetmez. Bu, birden fazla SaaS ekibini etkileyen gerçek bir production hatasıdır.

Somut Bir Örnek: Gerçek Token Timestamp'lerini Çözmek

Diyelim ki kimlik doğrulama servisin, bir kullanıcı 1 Temmuz 2025'te sabah 10:00 UTC'de giriş yaptıktan sonra şu JWT payload'ını üretiyor:

{
  "sub": "user_8821",
  "iat": 1751364000,
  "exp": 1751367600,
  "role": "admin"
}

Bu sayıların ne anlama geldiğini birlikte inceleyelim:

Fark tam olarak 3.600 saniyedir, yani bir saattir. Bu token'ı 11:00:00 UTC'den sonra alan her sunucu onu reddetmek zorundadır. Bunu elle doğrulamak için iat 'ı exp 'den çıkarırsın: 1751367600 - 1751364000 = 3600 saniye. Bu değerlerin herhangi birinin okunabilir karşılığını bir Unix timestamp dönüştürücüyle anında doğrulayabilirsin. Bu, daha önce bahsedilen milisaniye-saniye hatasını önleyen tam da bu tür hızlı bir akıl yürütme kontrolüdür.

Veritabanlarının bu değerleri nasıl saklaması gerektiğine dair daha fazla bağlam için veritabanlarında Unix timestamp'leri rehberimize göz at. Aynı integer formatı, exp değerini bir token'da ya da bir denetim logu tablosunda saklıyor olsan da geçerlidir.

Saat Kayması: Sessiz Token Katili

Ekipleri hazırlıksız yakalayan gerçek bir kısıtlamadan bahsedelim. Dağıtık bir sistemde kimlik doğrulama sunucun ve API sunucun iki farklı makinedir. Sistem saatleri NTP aracılığıyla senkronize edilir; ancak hiçbir zaman mükemmel biçimde hizalı değildir. Bulut ortamlarında 30 ila 90 saniyelik bir fark oldukça yaygındır.

Şu senaryoyu düşün: exp = 1751367600 değerine sahip bir token, saati 1751367610'u gösteren, yani son kullanma süresinin yalnızca 10 saniye geçtiği bir API sunucu tarafından doğrulanıyor. Token reddedilir. Kullanıcı 401 hatası alır. Kullanıcının perspektifinden bakıldığında az önce giriş yapmıştır ve uygulama bozulmuştur.

Standart çözüm, doğrulama mantığına bir saat kayması toleransı eklemektir. JWT kütüphanelerinin çoğu bir leeway (tolerans) parametresini destekler. 60 saniyelik bir değer yaygın biçimde kabul görmekte olup OpenID Connect Core spesifikasyonunda da referans olarak yer almaktadır. Bu değeri ayarla, belgele ve stack'indeki her servisin aynı değeri kullandığından emin ol.

SaaS Ürününe Uygun Token Expiry Süresini Seçmek

Doğru token expiry değeri, uygulamanın hassasiyetine ve beklenen oturum davranışına göre değişir. İşte pratik bir çerçeve:

• Yüksek hassasiyetli uygulamalar (bankacılık, sağlık, yönetici panelleri): Access token'lar için 15 ila 30 dakika. Oturumları sessizce yenilemek için refresh token kullan.
• Standart SaaS uygulamaları (proje yönetimi, CRM, analitik): 1 ila 8 saat. Tipik çalışma oturumu uzunluğuyla eşleştir.
• Düşük riskli ya da yalnızca okuma yapan API'lar: 24 saate kadar; ancak hassas işlemlerde token rotasyonuyla birleştir.
• Makineden makineye servis token'ları: Daha uzun olabilir (günler veya haftalar); ancak dar kapsamlı tutulmalı ve belirli aralıklarla rotasyona uğratılmalıdır.

Token üretimi sırasında exp değerini hesaplamak için kullanışlı bir formül:

// Node.js örneği
const iat = Math.floor(Date.now() / 1000); // mevcut zamanı saniye cinsinden al
const ttl = 3600; // time-to-live: 1 saat, saniye cinsinden
const exp = iat + ttl;

const payload = {
  sub: userId,
  iat: iat,
  exp: exp
};

Milisaniyeden saniyeye dönüştürmek için 1000'e bölme işlemine dikkat et. Bu tek satır, JavaScript uygulamalarındaki en yaygın JWT timestamp hatasını önler.

Güvenli JWT Expiration Uygulamak için Adım Adım Yol Haritası

Bugün herhangi bir SaaS kimlik doğrulama sistemine uygulayabileceğin somut bir kontrol listesi:

1. Her zaman hem iat hem de exp ekle. iat claim'i teknik olarak isteğe bağlıdır; ancak bir denetim izi oluşturur ve son kullanma süresinden bağımsız olarak maksimum yaş politikası uygulamanı sağlar.
2. Deploy etmeden önce timestamp formatını doğrula. Token'ını çöz ve exp 'nin 10 haneli bir integer olduğunu kontrol et. 13 haneli bir değer, milisaniyenin sızdığı anlamına gelir.
3. Doğrulama middleware'ine 60 saniyelik saat kayması toleransı ekle. Auth token'ları tüketen her serviste tutarlı biçimde uygula.
4. Kısa ömürlü access token'ları refresh token'larla birlikte kullan. 7 günlük refresh token ile eşleştirilmiş 15 dakikalık bir access token, tek başına 7 günlük bir access token'dan çok daha güvenlidir; çünkü refresh token sunucu tarafında iptal edilebilir.
5. Kimliği doğrulanmış her istekte iat değerini logla. Bu sayede aynı token'ın aynı anda iki farklı coğrafi bölgeden kullanılması gibi anomalileri tespit edebilirsin.
6. Staging ortamında hızlandırılmış zamanla expiry'yi test et. Saatini exp değerinin ötesine atlamak için mock'la ve uygulamanın çökmek ya da döngüye girmek yerine 401'i düzgün şekilde işlediğini doğrula.

Bir token'dan ham bir exp değerini okunabilir bir tarihe hızlıca dönüştürmek ya da belirli bir süre için hangi timestamp'i ayarlaman gerektiğini doğrulamak istersen, ana sayfamızdaki epoch dönüştürücü her iki yönde de anında sonuç verir; kod gerekmez.

Sonuç

JWT expiration karmaşık bir kavram değildir; ancak küçük hatalar büyük güvenlik açıkları yaratır. exp ve iat claim'leri, epoch'tan bu yana saniye cinsinden sayılan Unix timestamp'lerinden ibaret birer integer'dır. Bu sadelik onların gücüdür: her sunucu, her dil ve her platform iki sayıyı belirsizlik olmadan karşılaştırabilir. Asıl beceri bunları doğru uygulamakta yatar: makul bir token expiry süresi seçmek, saat kaymasını bir tolerans penceresiyle yönetmek ve milisaniye-saniye hatasını production'a taşımadan yakalamak. Bu alışkanlıkları auth pipeline'ına entegre edersen, JSON web token implementasyonun hem güvenli hem de sürdürülebilir olur.

JWT Timestamp'lerini Anında Doğrula - Kod Gerekmez

JWT payload'ından herhangi bir Unix timestamp'i yapıştır ve tek tıklamayla okunabilir bir tarihe dönüştür. Milisaniye-saniye hatalarını production'a ulaşmadan yakala.

Ücretsiz Aracı Dene →