JWS

JWS (JSON Web Signature, RFC 7515), JWT'nin üzerine inşa edildiği kriptografik imza çerçevesidir. Bir JWS, nokta ile birleştirilmiş üç bölümden oluşur: başlık.yük.imza; her segment base64url kodludur. Başlık, algoritmayı bildiren JSON'dur; yük herhangi bir bayt olabilir (genellikle ama zorunlu olarak JSON değil); imza, bildirilen algoritmayı kullanarak nokta ile birleştirilmiş başlık ve yük üzerinden hesaplanır.

JWT ilişkisi: her JWT, yükünün bir JSON iddia nesnesi olması gereken bir JWS'dir. Ancak JWS'nin kendisi daha geneldir — yük ham ikili, XML belgesi veya başka bir bayt dizesi olabilir. Orta segmenti JSON'a base64 çözümlenmeyen üç parçalı nokta-ayrılmış bir tokenla karşılaştığınızda, bu bir JWS'dir, JWT değil.

Yaygın algoritmalar: HS256 (HMAC-SHA256, simetrik anahtar), RS256 (RSA-SHA256, asimetrik), ES256 (ECDSA-P256-SHA256, asimetrik). Tehlikeli "none" algoritması "imza yok" anlamına gelir — spesifikasyon açısından geçerli ama sunucu tarafında her zaman reddedilmelidir. Üretim doğrulayıcıları ayrıca başlıkta bildirilen algoritmanın anahtar için beklenen algoritmayla eşleştiğini açıkça kontrol etmelidir.

JWS'nin iki serileştirmesi var: sıkıştırılmış (JWT'nin kullandığı nokta-ayrılmış biçim) ve JSON (aynı üç parçayı saran, aynı yük için birden fazla imzayı destekleyen bir JSON zarfı). Sıkıştırılmış biçim hemen hemen her API'nin kullandığı biçimdir; JSON biçimi belirli protokoller dışında nadirdir.

Çalışılmış örnek

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyJ9.4Adcj3UFYzPUVaHwte4eBI6vsjOvpz0yiwIM0F7sjuk JWS'ini alın. Başlığı (birinci segment) çözümleyin: {"alg":"HS256"} — HMAC-SHA256 imzası. Yükü (ikinci segment) çözümleyin: {"sub":"user_123"}. İmza (üçüncü segment), paylaşılan gizli anahtarı kullanarak eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyJ9'ın HMAC-SHA256'sıdır. Doğrulayıcı HMAC'ı yeniden oluşturur ve sabit zaman karşılaştırmasıyla karşılaştırır; uyuşmazlık → reddet. Şimdi RS256 ile karşılaştırın: aynı yapı, ancak imza RSA-SHA256'dır; verici özel anahtarla imzalar ve doğrulayıcılar açık anahtarla kontrol eder. Token baytları daha uzundur (RSA imzaları, 2048 bitlik bir anahtar için HMAC-SHA256'nın 43'üne karşılık yaklaşık 342 base64 karakterdir), ancak doğrulama semantiği çağıranın perspektifinden aynıdır.

Ne zaman ve neden önemli

JWS, bir hizmetin JWT verdiğinde, ilettiğinde veya kabul ettiğinde önemlidir — ki 2026'da bu çoğu API demektir. Son on yılda tekrar eden CVE'lere yol açan hatalar: (1) imzayı hiç doğrulamamak, yalnızca JSON olarak ayrıştırıldığı için yükü güvenilir kabul etmek; (2) alg: none'ı kabul etmek, imzayı tamamen kaldırıyor; (3) tokenın bildirdiği herhangi bir algoritmayı kabul etmek, HS256-RSA-açık-anahtarıyla-karışıklık saldırısını etkinleştiriyor; (4) exp'yi doğrulamamak, uzun süredir sona ermiş tokenların yeniden oynatılmasına izin veriyor; (5) iss ve aud'yi doğrulamamak, tamamen farklı hizmetler için verilen tokenları kabul ediyor. Savunma temeli: doğrulama çağrısında beklenen algoritmayı sabitleyin, doğrulama anahtarını güvenilir bir kaynaktan alın (tipik olarak yapılandırma zamanında beyaz listeye alınan bir JWKS URL, tokenın kendi jku'su değil) ve exp, iss ve aud'yi imza sonrası ayrı kontroller olarak doğrulayın. Referans: RFC 8725 — JWT Güncel En İyi Uygulamaları.

Algoritma-karışıklık saldırısı neden CVE'lerde görünmeye devam ediyor: JWS güvenlik açıklarının uzun süredir devam eden bir ailesi, JWT kütüphanesine "bu token geçerli mi?" diye soran ve kütüphanenin doğrulama algoritmasını tokenın kendi başlığından seçmesine izin veren sunucuları içerir. Sunucunun RSA açık anahtarını (tanımı gereği herkese açık) bilen bir saldırgan, RSA açık anahtar baytlarını HMAC sırrı olarak kullanarak HMAC-SHA256 ile imzalanmış bir token oluşturabilir, başlığa alg: HS256 koyabilir ve pek çok kütüphane bunu doğrular. Önlem, doğrulamayı beklediğiniz algoritmaya kilitlemektir — tokenın onu belirlemesine izin vermek yerine açık bir argüman olarak doğrulama çağrısına geçirin. 2015'te birçok büyük kütüphaneye (Node'un jsonwebtoken'ı, Python'un pyjwt'si, çeşitli Java uygulamaları) karşı yapılan bu açıklaması, standart uyarıcı hikâyedir.

Ayrılmış JWS — yük gömmeye çok büyük olduğunda: RFC 7797, orta segmentin boş olduğu ve yükün bant dışı iletildiği (örn. HTTP gövdesi olarak, JWS bir başlıkta) "ayrılmış yük" modunu tanımlar. Bu, bazı finansal API'lerin megabaytlarca JSON'ı yeniden base64 kodlamadan büyük istek gövdelerini imzalama yoludur. İmza hâlâ orijinal yük baytları üzerinden hesaplanır; yalnızca kablo biçimi değişir. Referans: RFC 7515 — JSON Web Signature.