JWT reddi sureden mi geliyor, yoksa imza dogrulamasi mi kirik?
Ayni "invalid token" veya "unauthorized" cevabi iki farkli kaynaktan gelebilir: token zaman olarak artik gecerli degildir ya da secret/public key tarafinda verify yanlistir. Bu guide, JWT Decoder/Verifier icindeki `ignore exp`, `ignore nbf`, algoritma secimi ve `secret Base64` davranisini kullanarak iki hata sinifini ayirmaya yardim eder.
4 adimli ayrim akisi
-
1. Decode ile claim ve algoritmayi oku
Once token'i decode edip header icindeki `alg` alanini, payload icindeki `exp` ve `nbf` claim'lerini gorunur hale getirin. Bu adim verify yapmaz ama hangi hata sinifina bakacaginizi belirler.
-
2. exp ve nbf'yi Timestamp ile insan okunur tarihe cevir
Token reddi zaman kaynakliysa bunu en hizli epoch alanlarini UTC ve yerel saat olarak yorumlayarak anlarsiniz. Saat drift'i olan sistemlerde sorun token'da degil ortam saatinde olabilir.
-
3. Verify akisinda ignore exp/nbf ile imzayi izole et
JWT aracinda `ignore exp` ve gerekirse `ignore nbf` acikken verify sonucu gecerliyse, temel imza katmani buyuk ihtimalle saglamdir ve reddedilme sure kontrolunden geliyordur.
-
4. Algoritma ve secret/public key secimini temizle
HS256 icin secret, RS256 veya ES256 icin PEM/JWK gerekir. HS* akisinda `secret Base64` secimi yanlissa, zaman dogru olsa bile verify sonucu signature mismatch verir.
En sik 3 ayrim noktasi
Bu genelde signature katmaninin saglam, zaman kontrolunun problemli oldugunu gosterir. Sonraki adim exp/nbf tarihlerini ve clock drift'i kontrol etmektir.
Bu durumda once algoritma, secret/public key kaynagi ve HS* icin `secret Base64` toggle'ina bakin. Sorun buyuk ihtimalle signature tarafindadir.
Decode edilebiliyor olmak token'in gecerli oldugu anlamina gelmez. Icerik okunabilir ama imza veya sure kosullari yine hatali olabilir.
JWT reddi okurken mini checklist
header.alg = HS256
payload.exp = 1716207000
payload.nbf = 1716203400
verify = invalid signature- Token su an exp disina cikmis mi?
- `ignore exp` acikken verify sonucu degisiyor mu?
- HS256 icin dogru secret ve dogru Base64 secimi kullaniliyor mu?
- Header'daki `alg` ile verifier secimi ayni mi?
Bu use-case'te hangi araci ne zaman acarsin?
Decode, verify, ignore exp/nbf ve secret Base64 ayarlariyla ana ayrim araci.
exp ve nbf claim'lerini UTC ve yerel saat baglaminda okumaya yardim eder.
HS* secret davranisini JWT verifier disinda izole test etmek icin yardimcidir.
Genel auth triage akisini daha genis baglamda toplar; bu sayfa ise ayrim sorusuna odaklanir.
Sik sorulanlar
ignore exp acik verify sonucu production karari icin yeterli mi?
Hayir. Bu yalnizca imza katmanini ayirmak icin gecici bir debug adimidir. Production kabul karari normal zaman kontrolleri acikken verilmelidir.
secret Base64 kutusunu ne zaman denemeliyim?
HS* verify tarafinda secret environment degiskeni base64 saklaniyorsa bu secim kritik olur. Ayni secret'i iki formatta yorumlamak farkli baytlar uretir.
RS256/ES256 akisinda da ayni ayrim gecerli mi?
Evet. Zaman claim'leri ve imza dogrulamasi hala ayridir; ancak burada secret yerine PEM/JWK uyumu ve key rotasyonu daha on plandadir.
JWT reddini simdi ayir
Ayni token uzerinde decode, timestamp yorumu ve verify ayarlarini birlikte denemek sorunun zaman mi imza mi oldugunu hizla netlestirir. Once claim'leri oku, sonra ignore exp ile imza katmanini izole et.