Guide 02 / JWT Debug

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.

Ilk bakis
Decode
header ve payload icerigini once ayikla
Zaman kontrolu
exp / nbf
claim zamanlariyla reddedilme sebeplerini ayir
Guven
Verify
algoritma ve anahtar uyumunu signature tarafinda test et
Workflow

4 adimli hizli auth triage

  1. 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. 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. 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. 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.

Common Checks

En sik 3 hata sinifi

1. Algoritma uyumsuzlugu

Header `HS256` derken verifier `RS256` ile deneniyorsa sonucu yanlis yorumlarsiniz. Ilk kontrol noktasi her zaman `alg` alanidir.

2. Sure / saat problemi

`exp` gecmis olabilir veya `nbf` claim'i henuz aktif degildir. Saat drift'i olan ortamlarda hata signature degil zamanlama kaynakli olabilir.

3. Anahtar / secret kaynagi farki

Yanlis secret, base64 flag uyumsuzlugu veya eski public key kullanimi verify hatasinin en yaygin sebeplerindendir.

Example

JWT debug sirasi ornek checklist

Header / payload tarafinda bak
header.alg = HS256
payload.sub = user_42
payload.exp = 1716207000
payload.nbf = 1716203400
payload.iss = api.example.com
Verify tarafinda sor
  • 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?
Tool Stack

Bu use-case'te hangi araci ne zaman acarsin?

FAQ

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.

CTA

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.