JWT (JSON Web Token), IETF tarafından RFC 7519'da tanımlanan (RFC 7515 JWS imza biçimini açıklar, RFC 7516 JWE şifrelemeyi açıklar, RFC 7517 JWK anahtarlarını tanımlar), HTTP istekleri, OIDC akışları ve mikroservis çağrıları arasında 'beyan edilmiş' kullanıcı bilgilerini güvenli bir şekilde taşımak için kullanılan açık bir standarttır. Standart bir JWT dizesi, Base64URL ile kodlanmış üç segmentten oluşur: Header (algoritma ve tür), Payload (Claims, kullanıcı verileri) ve Signature (ilk ikisi üzerinde anahtar tabanlı bir imza). Üç segment bir nokta `.` ile birleştirilir, örn. `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.
**JWT şifreleme değildir.** Bu en yaygın yanılgıdır. Payload varsayılan olarak düz metindir — herkes Base64URL ile decode edip içeriği okuyabilir. JWT **kurcalama tespiti** sağlar, gizlilik değil: sunucu Header.Payload'ı paylaşılan anahtarla yeniden imzalar ve tokenın Signature'ı ile karşılaştırır. Eşleşirlerse, token aktarım sırasında değiştirilmemiştir. Bu, 'sahtecilik önleyici damgalı tren bileti' metaforudur: müfettiş biletin gerçek olup olmadığıyla ilgilenir, QR kodunun okunup okunamayacağıyla değil.
JWT sorumlulukları 13 algoritma arasında net bir şekilde bölüştürür. **HMAC ailesi** (HS256/HS384/HS512) imza ve doğrulama için simetrik bir anahtar kullanır, hızlı ve basittir, tek bir servis veya güvenilir küme için uygundur; secret en az digest uzunluğunda olmalıdır (örn. HS256 için ≥ 32 bayt). **RSA ailesi** (RS256/RS384/RS512) en yaygın asimetrik şema olan RSASSA-PKCS1-v1_5 kullanır — imzalayanların özel anahtarı vardır, doğrulayanların genel anahtarı vardır. **RSA-PSS ailesi** (PS256/PS384/PS512) daha güçlü güvenlik garantileriyle daha yeni RSA-PSS padding kullanır, AWS SigV4 ve modern OIDC kimlik sağlayıcıları tarafından tercih edilir. **ECDSA ailesi** (ES256/ES384/ES512) daha kısa imzalar ve daha iyi performansla eliptik eğriler (sırasıyla P-256/P-384/P-521) kullanır. **EdDSA** (çoğunlukla Ed25519) son derece hızlı ve deterministiktir (aynı mesaj + aynı anahtar = her seferinde aynı imza) ve OAuth 2.1 ile yeni protokollerde önerilen algoritmadır.
Güvenlik, JWT'nin üretimde tökezlediği yerdir. OWASP JWT Cheat Sheet en az dört katı kuralı sıralar: (1) Payload'a asla parolaları, ulusal kimlik belgelerini, kart numaralarını veya API anahtarlarını düz metin olarak koymayın; (2) sunucu Tokenın Header'ında beyan edilen **alg alanına asla güvenmemelidir** — sabit kodlu bir algoritmayla doğrulamalıdır, aksi takdirde başlığı `alg: none` olarak yeniden yazan bir saldırgan her şeyi atlatır (bu, CVE-2015-9235 gibi tarihi CVE'lerin kaynağıdır); (3) HMAC secret'ları rastgele olmalı ve en az 32 bayt uzunluğunda olmalı, asla kısa dizeler değil; (4) doğrulama sadece imza kontrollerinden fazlasıdır — ayrıca `exp` (sona erme), `nbf` (not-before), `iss` (veren) ve `aud` (hedef kitle) değerlerini de doğrulamalısınız. Bu araç, bu Claims'lerin her birini UI'da vurgular, böylece bir arızanın imza sorunu mu, zaman sorunu mu yoksa Claims sorunu mu olduğunu bir bakışta görebilirsiniz.
JWT oturumların yerini almaz. Oturumlar kullanıcı durumunu sunucuda depolar (Redis veya veritabanı); JWT durumu tokena paketler. Mikroservis mimarileri, durumsuz API'ler, mobil istemciler ve çok fazla CORS içeren kurulumlar JWT'den faydalanır; geleneksel kurumsal sistemler ve anında iptal gerektiren akışlar (örn. 'bu kullanıcıyı şimdi at') hala oturumlar tarafından daha iyi hizmet alır. Bu araç, saf JWT hata ayıklamasının yanı sıra oturumdan JWT'ye geçişin Token parse / imza doğrulama / Payload düzenleme adımlarını da kapsar.