JWE

JWE (JSON Web Encryption, RFC 7516), JOSE (JSON Object Signing and Encryption) ailesindeki şifreleme çerçevesidir; JWS'nin kardeşidir. JWS bir yükü imzalarken (yükü okunabilir bırakır ama değiştirilmişse bunu gösterir), JWE yükü şifreler (içeriklerini gizli tutar).

JWE sıkıştırılmış serileştirme tokenı, JWT'nin üç segmenti yerine beş nokta ile ayrılmış segmente sahiptir:

1. Başlık — şifreleme algoritmalarını bildiren JSON.
2. Şifreli İçerik Şifreleme Anahtarı (CEK) — yük için kullanılan simetrik anahtar; alıcının anahtarıyla şifrelenmiş halde.
3. Başlangıç Vektörü (IV) — şifreleme başına rastgele nonce.
4. Şifreli metin — gerçek şifreli yük.
5. Kimlik doğrulama etiketi — AEAD modları için; şifreli metnin değiştirilmediğini doğrular.

JWE hibrit bir şema kullanır: simetrik bir anahtar (CEK) yükü şifreler (çünkü simetrik kriptografi hızlıdır), ardından asimetrik bir anahtar CEK'i şifreler (çünkü asimetrik şifreleme, paylaşılan sır olmadan anahtarların değiştirilebilmesinin tek yoludur). Standart algoritmalar: anahtar sarma için RSA-OAEP, yük şifrelemesi için A256GCM.

JWE ile JWT arasında ne zaman seçim yapılır: çoğu kimlik doğrulama sistemi JWT (imzalı ancak şifrelenmemiş) kullanır; çünkü iddialar gizli değildir — "sub: kullanıcı_123, exp: ..." içeren bir token okunabilir olsa da sorun olmaz. Token, gerçekten hassas yük (tıbbi kayıtlar, finansal ayrıntılar, yalnızca dahili yönlendirme verileri) içerdiğinde ve aracıların bunu incelemeyeceğini garanti edemediğinizde JWE kullanın. Modern sistemlerin çoğu, hassas verileri sunucuda tutmayı ve kısa opak oturum kimliği kullanmayı tercih eder — JWE'den çok daha basittir.

Çalışılmış örnek

Bir token verici, tarayıcı üzerinden aşağı akış hizmetine tıbbi kayıt referansı göndermesi gerekiyor; ancak tarayıcının bunu okuyamaması gerekiyor. Verici bir JWE oluşturuyor: başlık {"alg":"RSA-OAEP-256","enc":"A256GCM","cty":"JWT","kid":"recipient-2026"}, yük {"patient_id":"P-12345","record_id":"R-78910"}. Verici, 256 bit rastgele bir CEK üretir, yükü bu anahtar altında AES-256-GCM ile şifreler (şifreli metin + 128 bit kimlik doğrulama etiketi üretir) ve CEK'i alıcının RSA açık anahtarıyla şifreler. Çıktı, nokta ile birleştirilmiş beş base64url kodlu segmenttir — toplam yaklaşık 600-800 bayt. Alıcı ters sırayla çözer: özel anahtarını kullanarak RSA ile CEK'i açar, CEK ile AES-GCM yükü çözer, kimlik doğrulama etiketinin eşleştiğini doğrular. Beş segmentten herhangi birinde yapılan değişiklik, kimlik doğrulama etiketi kontrolünü başarısız kılar ve alıcı tokenı reddeder. Aradaki JWE'yi taşıyan tarayıcı yalnızca opak base64 görür — hasta/kayıt kimlikleri erişilemez durumdadır.

Ne zaman ve neden önemli

JWE, bir tokenın güvenilmez aracılardan geçerken gizli iddialar (hasta verileri, finansal yönlendirme ayrıntıları, dahili kullanıcı tanımlayıcılar) taşıması ve mimari olarak sunucu tarafı oturumu yerine token kullanması gerektiğinde önemlidir. Kaçınılacak hata, önce JWE'ye başvurmaktır; daha basit bir mimari işe yaradığında: çoğu kimlik doğrulama akışı, yalnızca referanslar (bir kullanıcı kimliği, bir oturum kimliği) içeren ve aracıların zararsızca görebileceği imzalı JWT'lerle daha iyi sonuç verir; hassas veri ise verenin veritabanında kalır. Aracıların operasyonel olarak tokena sahip olması gerektiğinde ancak sözleşmesel veya hukuki olarak onu okumalarının kısıtlandığında JWE kullanın — kuruluşlar arası federatif SSO, sağlık hizmetleri sağlayıcıları arasında sağlık verisi alışverişi, bazı açık bankacılık PSD2 akışları. İkinci hata, yanlış algoritma seçimidir: SHA-1 ile RSA-OAEP kullanımdan kaldırıldı, RSA-OAEP-256 güncel öneridir; A128CBC-HS256 hâlâ kabul edilebilir ancak yeni dağıtımlar için A256GCM tercih edilir. Referans: RFC 7518 — JSON Web Algoritmaları.

İç içe JOSE — önce imzala sonra şifrele: hem özgünlüğe (kanıtlanabilir kaynak) hem de gizliliğe ihtiyaç duyan tokenlar için standart model önce-imzala-sonra-şifrele'dir: yük önce bir JWS'ye sarılır, ardından JWS'nin tamamı bir JWE'nin yükü haline gelir. Dış JWE'deki başlık alanı cty: "JWT", ayrıştırıcıya şifresi çözülen içeriğin kendisinin de doğrulanacak bir JOSE tokeni olduğunu bildirir. Ters sıralama (önce şifrele sonra imzala), imzanın farklı alıcılara yeniden oynatılabilecek şifreli metin üzerinde olacağından daha az güvenlidir. JWE kullanan kurumsal SSO platformlarının çoğu (Microsoft Azure AD federasyon tokenları, bazı bankacılık API'leri) standart olarak önce-imzala-sonra-şifrele kullanır. Referans: RFC 7516 — JSON Web Encryption.