JWT Token Çözümleme

Çözülmüş Header

{
  "alg": "HS256",
  "typ": "JWT"
}

Çözülmüş Payload

{
  "sub": "1234567890",
  "name": "John Doe",
  "email": "john@example.com",
  "role": "admin",
  "iat": 1516239022,
  "exp": 1735689600
}

İmza

TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

İmza çözülemez. Bu, kodlanmış veri değil, bir HMAC-SHA256 işleminin çıktısıdır. Doğrulamak için, token verilirken kullanılan gizli anahtara ihtiyacınız vardır.

Üç Parçalı JWT Yapısı

Bir JWT, noktalarla birleştirilmiş üç Base64url kodlu bölümdür:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0
.
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Yapı, RFC 7519 ve RFC 7515 ile tanımlanmıştır. Her bölüm farklı bir amaca hizmet eder:

Header

Header, token türünü ve imzalama algoritmasını belirtir. alg, doğrulayıcıya imzayı hesaplamak için hangi algoritmanın kullanıldığını söyler. typ, standart token’lar için her zaman JWT’dir. Bazı token’lar ayrıca hangi anahtarın kullanıldığını belirtmek için kid (key ID) içerir; bu, bir yetkilendirme sunucusu anahtarları döndürdüğünde önemlidir.

Payload

Payload, claim’leri içerir: özne hakkındaki ifadeler ve ek meta veriler. Standart kayıtlı claim’lerin token’ları kompakt tutmak için kısa adları vardır (sub, iss, exp). Özel claim’ler uygulamanızın ihtiyaç duyduğu her şey olabilir, ancak JWT spesifikasyonu çakışmaları önlemek için özel claim’ler için ad alanlı bir format kullanılmasını önerir (örneğin, https://myapp.com/role).

İmza

İmza, header’da belirtilen algoritma kullanılarak base64url(header) + "." + base64url(payload) üzerinden hesaplanır. HS256 için bu HMAC-SHA256(secret, data)’dır. RS256 için RSA-SHA256(privateKey, data)’dır. Doğrulayıcı, alınan header ve payload’dan imzayı yeniden hesaplar ve üçüncü bölümle karşılaştırır. Eşleşmezlerse, token kurcalanmıştır.

Base64url Kodlama

JWT’ler, Base64’ün URL güvenli bir varyantı olan Base64url kullanır. + yerine - ve / yerine _ kullanır ve = dolgu karakterlerini atlar. Bu, JWT token’larının URL sorgu parametrelerine ve HTTP başlıklarına yüzde kodlama gerektirmeden dahil edilmesini güvenli hale getirir.

Standart Base64, = dolgu karakterleri gerektirir ve URL’lerde özel anlamı olan + veya / içerebilir. Base64url, URL’lerde kaçış gerektirmeyen karakterleri kullanarak bunların hepsinden kaçınır.

Payload bölümünü manuel olarak çözmek için:

# Payload bölümü (iki nokta arasındaki orta kısım)
PAYLOAD="eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0"

# Dolgu ekle ve çöz (macOS/Linux)
python3 -c "
import base64, json, sys
s = sys.argv[1]
pad = s + '=' * (4 - len(s) % 4)
decoded = base64.urlsafe_b64decode(pad)
print(json.dumps(json.loads(decoded), indent=2))
" "$PAYLOAD"

Standart Claim’ler Açıklaması

Tüm claim’ler gerekli değildir. exp ve sub en yaygın kullanılanlardır. aud claim’i, aynı yetkilendirme sunucusunu paylaşan hizmetler için önemlidir. Bu olmadan, A hizmeti için tasarlanmış bir token B hizmetine karşı kullanılabilir.

Çözmek Güvenmek Anlamına Gelmez

JWT çözücüleri hakkında anlaşılması gereken en önemli şey budur. Bir token’ı çözmek, içindeki claim’leri ortaya çıkarır. Bu claim’lerin doğru olup olmadığını veya token’ın meşru olup olmadığını söylemez.

Bir saldırgan istediği herhangi bir JWT’yi elle oluşturabilir. İmza doğrulaması olmadan, gerçek bir token’ı sahte olandan ayırmanın bir yolu yoktur. Bu önemlidir çünkü:

1. alg: none saldırısı. Bazı eski JWT kütüphaneleri, header’da "alg": "none" olan ve imzası olmayan token’ları geçerli kabul ederdi. İmzasız token’ları asla kabul etmeyin.

2. Algoritma karışıklığı saldırıları. Sunucunuz RS256 (asimetrik) kullanıyorsa, bir saldırgan header’da "alg": "HS256" olan ve genel anahtarınızı HMAC gizli anahtarı olarak kullanan bir token gönderebilir. Zayıf algoritma uygulamasına sahip kütüphaneler bunu başarıyla doğrular. Beklenen algoritmayı her zaman açıkça belirtin.

3. Süresi dolmuş token’lar. Çözme, exp claim’ini ortaya çıkarır, ancak yine de geçerli zamanın onu geçip geçmediğini kontrol etmeniz gerekir.

Üretimde, doğrulama, algoritma sabitleme ve süre sonu kontrolünü yöneten, iyi bakımı yapılan bir JWT kütüphanesi kullanın. JWT doğrulamasını asla kendiniz uygulamayın.

JWT’ler Nerelerde Kullanılır

OAuth 2.0 / OpenID Connect

OAuth akışlarındaki access token’lar ve ID token’ları sıklıkla JWT’dir. OIDC’deki ID token her zaman bir JWT’dir. Access token’lar, yetkilendirme sunucusuna bağlı olarak JWT olabilir veya olmayabilir.

API kimlik doğrulaması

Bir sunucu, bir kullanıcı oturum açtığında bir JWT verir. İstemci, sonraki isteklerde bunu Authorization: Bearer <token> başlığında gönderir. Sunucu, imzayı doğrular ve kullanıcıyı tanımlamak ve izinleri kontrol etmek için claim’leri okur.

Durumsuz oturum verileri

Bazı uygulamalar, her istekte bir veritabanı sorgusunu önlemek için oturum durumunu (kullanıcı ID’si, rol, tercihler) JWT payload’ında kodlar. Takas: token’lar, ek altyapı olmadan (bir kara liste veya kısa süre sonu + refresh token’lar) süre sonundan önce iptal edilemez.

Servisten servise kimlik doğrulaması

İç mikro hizmetler, genellikle kısa süre sonu süreleriyle (saatler yerine dakikalar) birbirlerine yapılan çağrıları doğrulamak için JWT’leri kullanır.

JWT Sorunlarını Hata Ayıklama

JWT ile doğrulanmış bir istek başarısız olduğunda, bir çözücü ulaşılacak ilk araçtır:

• Token’ın süresi dolmuş mu? exp değerini geçerli Unix zamanıyla karşılaştırın.
• Hedef kitle (audience) doğru mu? aud değerinin hizmetinizin beklediğiyle eşleştiğini kontrol edin.
• Veren (issuer) doğru mu? iss değerinin yetkilendirme sunucu URL’nizle eşleştiğini kontrol edin.
• Özel claim’ler mevcut mu? Uygulamanız role veya permissions claim’i bekliyorsa, payload’da olduklarını doğrulayın.
• Algoritma doğru mu? Header’daki alg değerinin doğrulama kodunuzun beklediğiyle eşleştiğini kontrol edin.

İmza hataları, teşhis için gerçek gizli veya genel anahtarı gerektirir. Bir çözücü size bir imzanın neden yanlış olduğunu söyleyemez, yalnızca onu oluşturmak için hangi algoritmanın kullanıldığını söyleyebilir.