JWT token decode ve verify akisini hizli debug rehberine cevir.
Token formatini okumak, exp/nbf claim'lerini ayirmak ve signature verify sorunlarini triage etmek ayni anda yapildiginda auth debugging daha hizli ilerler. Bu guide, JWT Decoder/Verifier etrafinda en kisa kontrol akisini toplar.
4 adimli hizli auth triage
-
1. Token formatini decode ederek basla
Token'in uc parcali JWT yapisinda olup olmadigini, `alg`, `typ`, `sub`, `aud`, `iss` ve diger claim'leri once decode ile okuyun. Bu adim imza dogrulamaz ama veri seklini netlestirir.
-
2. exp ve nbf claim'lerini ayri incele
Token reddediliyorsa sorun her zaman signature olmayabilir. `exp` gecmis olabilir, `nbf` gelecekte olabilir veya servis saat farki yasiyor olabilir. Bu claim'leri Timestamp ile insan okunur tarihe cevirerek kontrol etmek hiz kazandirir.
-
3. Algoritma ve anahtar tipini eslestir
HS* kullaniliyorsa secret, RS*/ES* kullaniliyorsa PEM veya JWK gerekir. Header'daki `alg` ile verifier'da secilen algoritma uyumsuzsa sonucu guvenilir okuyamazsiniz.
-
4. Signature sonucu ile claim analizini birlikte yorumla
Verify basarisizsa bunun secret/public key sorunu mu yoksa claim kaynakli ayrik bir hata mi oldugunu netlestirin. Gerekirse Hash / HMAC araci ile ayni secret mantigini izole test edin.
En sik 3 hata sinifi
Header `HS256` derken verifier `RS256` ile deneniyorsa sonucu yanlis yorumlarsiniz. Ilk kontrol noktasi her zaman `alg` alanidir.
`exp` gecmis olabilir veya `nbf` claim'i henuz aktif degildir. Saat drift'i olan ortamlarda hata signature degil zamanlama kaynakli olabilir.
Yanlis secret, base64 flag uyumsuzlugu veya eski public key kullanimi verify hatasinin en yaygin sebeplerindendir.
JWT debug sirasi ornek checklist
header.alg = HS256
payload.sub = user_42
payload.exp = 1716207000
payload.nbf = 1716203400
payload.iss = api.example.com
- Secret dogru mu, yoksa eski environment degiskeni mi kullaniliyor?
- Base64 secret flag'i yanlis acik mi?
- Token su an exp disina cikti mi?
- Header'daki algoritma ile verifier secimi uyumlu mu?
Bu use-case'te hangi araci ne zaman acarsin?
Header/payload inceleme ve verify akisi icin ana arac.
Secret veya HMAC davranisini JWT verifier disinda izole test etmek icin yardimci olur.
exp ve nbf claim'lerini insan okunur tarihe cevirerek saat kaynakli hatalari ayiklar.
Base64 secret veya parca bazli encode/decode davranisini ayri test etmek icin kullanilabilir.
Sik sorulanlar
Decode edebiliyorsam token dogru mu demektir?
Hayir. Decode sadece icerigi okur; token'in guvenilirligini ve anahtar uyumunu anlamak icin verify gerekir.
ignore exp / nbf ne zaman kullanilir?
Auth triage sirasinda once signature tarafini izole etmek istediginizde gecici olarak kullanilabilir. Ancak production kararini bu bayraklar acikken vermemelisiniz.
HS* mi RS*/ES* mi oldugunu en hizli nereden anlarim?
JWT header icindeki `alg` alanina bakin. Bu alan hangi anahtar tipini ve verify stratejisini kullanacaginizi belirler.
JWT triage akisini simdi calistir
Rehberdeki sorulari ayni anda eldeki token uzerinde denemek, auth issue'larini okumaktan daha hizli cozer. Once decode, sonra exp/nbf kontrolu, en sonunda verify ve signature/secret ayrimi ile ilerleyin.