Skip to content

JWT Çözücü

Ücretsiz JWT çözücümüzle JWT token'larını online çözün. header, payload, signature, son kullanma, algoritma ve claim'leri anında inceleyin. %100 tarayıcıda çalışır — token'ınız cihazınızdan ayrılmaz. Kayıt yok, izleme yok.

Takip Yok Tarayıcıda Çalışır Ücretsiz
JWT Token
RFC 7519 uyumluluğu ve gizlilik garantileri için incelendi — Go Tools Güvenlik Ekibi · Apr 22, 2026

JWT nedir?

JSON Web Token, kısaca JWT (telaffuzu "jot"), iki taraf arasında claim taşımak için kullanılan kompakt, URL-güvenli bir token formatıdır. RFC 7519'da tanımlıdır ve OAuth 2.0 erişim token'ları, OpenID Connect ID token'ları, modern kimlik doğrulama sağlayıcılarındaki API anahtarları (Auth0, Okta, Clerk, Supabase, Firebase) ve mikroservis mimarilerindeki servis-arası token'lar için baskın kimlik bilgisi formatıdır.

"JSON Web Token (JWT), HTTP Authorization header'ları ve URI sorgu parametreleri gibi alanı kısıtlı ortamlarda kullanılmak üzere tasarlanmış, kompakt bir claim temsili formatıdır." — RFC 7519, Bölüm 1

Bir JWT, noktalarla birleştirilmiş üç adet Base64URL ile kodlanmış JSON nesnesidir: header.payload.signature. Header, token'ın nasıl imzalandığını tanımlar (alg claim'i — örneğin HS256 veya RS256 — ve genellikle "JWT" olan typ claim'i). Payload, claim'leri taşır: iss, sub, aud, exp, iat gibi kayıtlı claim'lerin yanı sıra issuer'ın ihtiyaç duyduğu özel claim'ler (role, scope, email, tenant ID). Signature ise header ve payload üzerinde issuer'ın gizli anahtarı veya özel anahtarıyla hesaplanan, alıcının değişiklikleri tespit etmesini sağlayan kriptografik bir kanıttır.

Kritik olarak, bir JWT kodlanmıştır, şifrelenmemiştir. Token'a sahip herkes payload'ı okuyabilir — çözüm yalnızca Base64URL ve JSON ayrıştırmadır. Güvenlik garantisi signature'dan gelir: bir saldırgan JWT'yi okuyabilir, ama imzalama anahtarı olmadan signature doğrulamasından geçecek farklı bir JWT üretemez. Bu yüzden JWT'leri ağ üzerinden geçirmek güvenlidir, ama içlerini sırlarla doldurmak güvensizdir.

Bir JWT çözücü size bir token'ın tam olarak ne içerdiğini — algoritma, claim'ler, son kullanma — signature'a dokunmadan gösterir. "Bu token'ın süresi doldu mu?", "Bu kullanıcının role'ü ne?", "Bu token'ı hangi issuer üretti?" ya da "Bu reddetmem gereken bir alg:none token'ı mı?" sorularını yanıtlamanın en hızlı yoludur. Bu araçtaki tüm çözüm tarayıcınızda yerel olarak çalıştığı için canlı bir üretim token'ını yapıştırmak güvenlidir.

JWT işi sıklıkla diğer geliştirici araçlarıyla birlikte yapılır. Hatalı biçimlendirilmiş bir token'ı ayıklarken Base64URL ile sarılmış bir segmenti çözmeniz, bir proxy'den yakalanan bir Authorization header'ını URL'den çözmeniz ya da exp claim'ini elle okunabilir bir tarihe dönüştürmeniz gerekebilir. JWT'lerin üretimde nasıl imzalandığı, doğrulandığı ve döndürüldüğüne dair daha derin bir gezi için Base64 temelleri rehberimize bakın — Base64URL, her JWT'nin üzerine inşa edildiği temeldir.

// Decode a JWT in the browser — header & payload only
function decodeJwt(token) {
  const [h, p, s] = token.split('.');
  const pad = (seg) => seg + '==='.slice((seg.length + 3) % 4);
  const decode = (seg) => JSON.parse(
    atob(pad(seg).replace(/-/g, '+').replace(/_/g, '/'))
  );
  return { header: decode(h), payload: decode(p), signature: s };
}

const { header, payload } = decodeJwt(token);
console.log(header);   // → { alg: 'HS256', typ: 'JWT' }
console.log(payload);  // → { sub: 'user_123', exp: 1999999999, ... }

// Expiration check
const expired = payload.exp * 1000 < Date.now();

Temel Özellikler

JWT'yi Anında Çözün

Yapıştırın ve JWT'nin gerçek zamanlı olarak çözülmesini izleyin — header, payload ve signature anında ayrıştırılır. Çöz düğmesi yok, sunucuya gidiş-dönüş yok.

Son Kullanma Tespiti

exp claim'ini otomatik okur ve token'ın süresi dolduğunda kırmızı bir rozet gösterir; tam son kullanma tarihini yerel saat diliminizde verir.

Algoritmadan Bağımsız

Her JWS algoritmasını çözer — HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512, EdDSA ve alg:none.

%100 Yerel

Çözüm yerel atob ve JSON.parse ile tarayıcınızda çalışır. Token'ınız asla yüklenmez — üretim kimlik bilgileri için güvenlidir.

Claim Bilinçli Görünüm

RFC 7519'daki kayıtlı claim'leri (iat, exp, nbf, iss, aud, sub, jti) öne çıkarır; kimlik doğrulama sorunlarını bir bakışta yakalarsınız.

Tek Tıkla Kopyalama

Header JSON'unu, payload JSON'unu veya ham signature'ı tek tıkla panonuza kopyalayın — hata raporları ve testler için ideal.

Örnekler

HS256 Token (Geçerli)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcxNTAwMDAwMCwiZXhwIjoxOTk5OTk5OTk5fQ.4NhxPjwoZxPNuxG-2C5ugGxaUsUJ0QyskAz7Ymz5Sg0
{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "sub": "user_123",
  "name": "Alice",
  "role": "admin",
  "iat": 1715000000,
  "exp": 1999999999
}

HMAC-SHA256 ile imzalanmış, subject, role ve gelecekte sona erecek bir exp içeren token — oturum kimlik doğrulamasında kullanılan en yaygın JWT yapısı.

RS256 Token (Süresi Dolmuş)

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImtleS0yMDI1LTAxIn0.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJhdWQiOiJhcGkuZXhhbXBsZS5jb20iLCJzdWIiOiI5MDA4NzE2NSIsImlhdCI6MTYwMDAwMDAwMCwiZXhwIjoxNjAwMDAzNjAwLCJzY29wZSI6InJlYWQ6dXNlciB3cml0ZTpwb3N0In0.signature_placeholder
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-2025-01"
}

{
  "iss": "https://auth.example.com",
  "aud": "api.example.com",
  "sub": "90087165",
  "iat": 1600000000,
  "exp": 1600003600,
  "scope": "read:user write:post"
}

RSA imzalı, OAuth tarzı bir erişim token'ı — header'daki kid (key ID) ve geçmişte kalmış exp claim'i token'ın çoktan süresinin dolduğunu gösteriyor.

OIDC ID Token

eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJzdWIiOiIxMTA1MDIyNTExNTU4OTkwNzY2Mzk1IiwiYXpwIjoiY2xpZW50LWlkIiwiYXVkIjoiY2xpZW50LWlkIiwiZW1haWwiOiJhbGljZUBleGFtcGxlLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJpYXQiOjE3MTUwMDAwMDAsImV4cCI6MTk5OTk5OTk5OSwibm9uY2UiOiJhYmMxMjMifQ.signature
{
  "alg": "ES256",
  "typ": "JWT"
}

{
  "iss": "https://accounts.google.com",
  "sub": "110502251155899076639",
  "azp": "client-id",
  "aud": "client-id",
  "email": "alice@example.com",
  "email_verified": true,
  "iat": 1715000000,
  "exp": 1999999999,
  "nonce": "abc123"
}

ECDSA imzalı, e-posta claim'leri ve tekrar saldırılarına karşı koruma sağlayan nonce içeren bir OpenID Connect ID token'ı.

Alg: none Token (İmzasız)

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJkZWJ1Zy11c2VyIiwiaWF0IjoxNzE1MDAwMDAwfQ.
{
  "alg": "none",
  "typ": "JWT"
}

{
  "sub": "debug-user",
  "iat": 1715000000
}

alg:none ile imzasız bir token. Üretimde bunu kabul etmek klasik bir JWT zafiyetidir — sunucu tarafında alg:none'ı her zaman reddedin.

Nasıl Kullanılır

  1. 1

    Çözmek İçin JWT'nizi Yapıştırın

    Tam JWT'yi — noktayla ayrılmış üç segmentin tümü dahil — giriş kutusuna yapıştırın. Çözücü tarayıcınızda anında çalışır; herhangi bir düğmeye tıklamanız gerekmez.

  2. 2

    Çözülmüş Header, Payload ve Durumu Okuyun

    Çözülen header'da algoritmayı ve token türünü, payload'da claim'leri, üst kısımdaki çiplerde ise son kullanma / düzenlenme bilgilerini okuyun. Süresi dolmuş bir token kırmızıyla işaretlenir.

  3. 3

    Çözülmüş Çıktıyı Kopyalayın

    Her panelin Kopyala düğmesini kullanarak çözülmüş header JSON'unu, payload JSON'unu veya ham signature'ı kopyalayın. Token'ınız hiçbir yere gönderilmedi — çözüm tarayıcınızda yerel olarak gerçekleşti.

Common Errors

alg:none'ı Kabul Etmek

İmzasız bir JWT herkes tarafından sahteleştirilebilir. Üretimde asla alg:none'a izin vermeyin — verify çağrınıza her zaman açık bir algoritma listesi geçirin.

✗ Yanlış
jwt.verify(token, secret)  // library default may allow 'none'
✓ Doğru
jwt.verify(token, secret, { algorithms: ['RS256'] })

exp Claim'inin Eksik Olması

exp'siz bir JWT sonsuza kadar yaşar. Bir token sızdırılırsa, doğal bir iptal noktası kalmaz. Token türüne uygun bir son kullanma her zaman ayarlayın.

✗ Yanlış
{ "sub": "user_123", "role": "admin" }  // no exp
✓ Doğru
{ "sub": "user_123", "role": "admin", "exp": 1715003600 }

Sırları Payload'da Saklamak

JWT payload'ları şifrelenmemiştir — token'a sahip olan herkes onları okuyabilir. Bir JWT payload'ının içine asla parolaları, API anahtarlarını ya da kısaltılmamış PII'yi koymayın.

✗ Yanlış
{ "sub": "user_123", "password": "hunter2" }
✓ Doğru
{ "sub": "user_123", "role": "admin" }  // payload stays minimal

Yaygın Kullanım Senaryoları

Authorization Bearer Token'larını Çözün
Authorization: Bearer header'larındaki JWT token'larını çözerek backend'inizin aldığı claim'leri, audience'ı ve son kullanmayı doğrulayın.
OAuth 2.0 ve OIDC Token'larını Çözün
OAuth 2.0 ve OpenID Connect entegrasyonu sırasında yetkilendirme sunucularından (Auth0, Okta, Google, Keycloak) dönen erişim token'larını ve ID token'larını çözün.
Süresi Dolmuş Oturum Teşhisi
Reddedilen bir token'ın süresinin dolup dolmadığını, yanlış audience kullanıp kullanmadığını ya da saat farkı sorunu olup olmadığını bir saniyede onaylayın.
Anahtar Rotasyonu Kontrolleri
Header'daki kid (key ID) değerini okuyarak JWKS rotasyonunuzun beklenen anahtarla imzalanmış token'lar dağıttığını doğrulayın.
Güvenlik İncelemeleri
Kod incelemesi ve sızma testlerinde alg:none ile imzalı, exp'i eksik ya da payload'ında PII sızdıran token'ları tespit edin.
Mikroservis Token İncelemesi
Bir servis ağı içinde servis-arası token'ları çözerek aşağı yöndeki çağrının hangi scope ve subject ile yetkilendirildiğini görün.

Teknik Ayrıntılar

RFC 7519 Uyumlu
RFC 7519 (JWT), RFC 7515 (JWS) ve RFC 7518 (JWA) ile uyumlu JWS token'larını işler — kayıtlı tüm algoritmalar çözüm için desteklenir.
Base64URL Çözümü
RFC 4648'de tanımlanan, URL-güvenli Base64 alfabesini kullanır (+ ve / yerine - ve _) ve eksik dolguya toleranslı ayrıştırma yapar.
Tarayıcı Yerel, Sıfır Bağımlılık
Tarayıcının atob, TextDecoder ve JSON.parse fonksiyonları üzerine kuruludur — dış kütüphane yok, ağ çağrısı yok, telemetri yok.

En İyi Uygulamalar

Doğrulamadan Asla Güvenmeyin
Çözücü claim'leri gösterir; onları kanıtlamaz. Herhangi bir claim'e güvenmeden önce signature'ı her zaman sunucu tarafında issuer'ın anahtarıyla doğrulayın.
Üretimde alg:none'ı Reddedin
JWT kütüphanenizi açık bir algoritma izin listesiyle yapılandırın. alg:none'ı asla kabul etmeyin ve anahtar rotasyonunda alg uyumsuzluklarına karşı şüpheci olun.
Payload'ları Yalın Tutun
JWT'ye yalnızca tanımlayıcıları ve kısa ömürlü claim'leri koyun; hacimli veriyi opak bir oturum kimliğinin arkasında tutun. Büyük token'lar her istekte bant genişliğine mal olur.

Sıkça Sorulan Sorular

Bir JWT token'ını online nasıl çözerim?
Tam JWT'yi — noktayla ayrılmış üç segmentin tamamını (header.payload.signature) — yukarıdaki çözücüye yapıştırın. Çözüm tarayıcınızda anında gerçekleşir: header ve payload, Base64URL'den okunabilir JSON'a çözülür, signature ise ham bir karakter dizisi olarak görüntülenir. Bir durum satırı imzalama algoritmasını, düzenlenme zamanını ve son kullanma tarihini öne çıkarır; böylece süresi dolmuş bir token'ı bir bakışta fark edebilirsiniz. Bir JWT'yi elle çözmek için token'ı noktalardan ayırın, ilk iki segmenti Base64URL'den çözün ve JSON olarak ayrıştırın — token'a sahip olan herkes claim'leri okuyabilir, çünkü payload kodlanmıştır, şifrelenmemiştir. Bu çözücü üretim token'larıyla güvenle kullanılabilir, çünkü hiçbir şey cihazınızdan ayrılmaz: ağ isteği yok, kayıt yok, izleme yok.
JWT (JSON Web Token) nedir?
JSON Web Token (JWT), iki taraf arasında claim taşıyan, kompakt ve URL-güvenli bir kimlik bilgisi formatıdır. RFC 7519'da tanımlanır ve noktalarla birleştirilmiş üç adet Base64URL ile kodlanmış bölümden oluşur: header (algoritma ve token türü), payload (claim'ler — kullanıcı ve token'ın kendisi hakkındaki veriler) ve signature (token'ın güvenilen bir tarafça düzenlendiğini gösteren kriptografik kanıt). JWT'ler, OAuth 2.0'da erişim token'larını ve OpenID Connect'te ID token'larını temsil etmenin standart yoludur.
Token'ım bu JWT çözücüde güvende mi?
Evet. Tüm çözüm işlemi yerel JavaScript (atob ve TextDecoder) kullanılarak tarayıcınızda çalışır. Token'ınız bir sunucuya hiçbir zaman gönderilmez, kaydedilmez, depolanmaz ve analitik için kullanılmaz. Çerez yok, izleme yok. Bu önemlidir çünkü JWT'ler aktif erişim token'ları içerebilir — uzak bir hata ayıklayıcıya yapıştırmak, doğrudan bir kimlik bilgisini teslim etmekle eşdeğerdir. Aracımız üretim token'larıyla güvenle kullanılabilir.
Bir JWT çözücü nasıl çalışır?
Bir JWT çözücü, token'ı noktalardan üç parçaya ayırır, header ve payload'ı Base64URL'den çözer ve onları JSON olarak ayrıştırır. Signature, opak bir Base64URL karakter dizisi olarak bırakılır; çünkü onu doğrulamak issuer'ın gizli anahtarını veya açık anahtarını gerektirir — ki bunu istemci tarafında çalışan bir çözücü güvenli biçimde yapamaz. Yani çözüm anında gerçekleşir ve claim'leri ortaya çıkarır, ama içindeki herhangi bir şeye güvenmeden önce signature'ı sunucu tarafında doğru anahtarla doğrulamanız gerekir.
Bu araç JWT signature'ını doğrular mı?
Hayır, bilinçli olarak doğrulamaz. Signature doğrulaması issuer'ın gizli anahtarını (HMAC için) ya da açık anahtarını (RSA/ECDSA/EdDSA için) gerektirir; bunlar asla herkese açık bir web aracına yapıştırılmamalıdır. Doğrulama sunucunuzda, kimlik doğrulama ara katmanınızda veya JWKS endpoint'inize erişimi olan bir SDK içinde gerçekleşmelidir. Bu çözücü, bir token'ın neyi iddia ettiğini incelemek içindir — token'ın özgün ya da değiştirilmemiş olduğunu ima etmez.
iat, exp, nbf, iss, aud, sub ve jti nedir?
Bunlar RFC 7519'daki kayıtlı claim'lerdir. iat (issued at) token'ın oluşturulduğu Unix zaman damgasıdır. exp (expiration) token'ın geçerliliğini yitirdiği andır — bu araç bunu okunabilir bir tarihe çevirir ve exp geçmişteyse token'ı süresi dolmuş olarak işaretler. nbf (not before) token'ın kullanılabileceği en erken andır. iss (issuer) token'ı kimin oluşturduğunu belirtir. aud (audience) hedef alıcıyı tanımlar. sub (subject) principal'ı — genellikle bir kullanıcı kimliğini — tanımlar. jti ise tekrar saldırılarını önlemek için kullanılan benzersiz bir token kimliğidir. Bunların yanında uygulamaya özgü claim'ler (role, scope, email, name) da yer alır.
JWT'imin süresi dolmuş — çözücü neden hâlâ çözüyor?
Çözmek doğrulamakla aynı şey değildir. Bir JWT çözücü, içeriği son kullanma tarihinden bağımsız okur; böylece süresi dolmuş ya da başka bir nedenle geçersiz bir token'ı inceleyip neden reddedildiğini anlayabilirsiniz. Bu araçtaki "Süresi Dolmuş" rozeti exp claim'ini yerel saatinizle karşılaştırır ve exp'i geçmişte kalan token'ları işaretler. Gerçek bir kimlik doğrulama sunucusu böyle bir token'ı doğrudan reddederdi — ama süresi dolmuş token'ları göstermeyen bir çözücü, hata ayıklamada işe yaramaz olurdu.
JWT, JWS ve JWE arasındaki fark nedir?
JWT genel kavramdır — kompakt bir token olarak kodlanmış bir JSON nesnesi. JWS (RFC 7515) imzalı bir JWT'dir: payload, onu çözen herkes tarafından okunabilir ve signature, üzerinde değişiklik yapılmadığını kanıtlar. Karşılaşacağınız JWT'lerin büyük çoğunluğu budur. JWE (RFC 7516) ise şifrelenmiş bir JWT'dir: payload'ın kendisi şifreli metindir ve şifre çözme anahtarı olmadan çözülemez. Bu araç JWS token'larını çözer. Bir JWE token'ında yalnızca header çözülebilir — şifrelenmiş payload, anahtar olmadan okunamaz.
alg:none neden tehlikeli?
alg:none içeren bir JWT'nin signature'ı yoktur — herkes böyle bir token üretip herhangi bir kullanıcı gibi davranabilir. İlk JWT kütüphaneleri alg:none'ı varsayılan olarak kabul ediyordu; bu da saldırganların signature'ı silip algnone'a ayarlayarak admin token'ı sahteciliği yaptığı, iyi bilinen bir kimlik doğrulama atlama sınıfına yol açtı. Olgun her JWT kütüphanesi artık alg:none'ı, açıkça izin verilmediği sürece reddeder ve siz de kimliği doğrulanmış istekler için bunu asla kabul etmemelisiniz. Bu çözücü size yine de bir alg:none token'ını gösterir, çünkü hata ayıklama sırasında incelemek meşrudur — ama üretimde gelen böyle bir token'ı her zaman düşmanca kabul edin.
Bu JWT çözücü hangi algoritmaları destekler?
Header ve payload'ı çözmek her algoritmada işler, çünkü çözüm yalnızca Base64URL ve JSON ayrıştırma gerektirir — algoritmadan bağımsızdır. Araç; HS256, HS384, HS512 (HMAC), RS256, RS384, RS512 (RSA + SHA), PS256, PS384, PS512 (RSA-PSS), ES256, ES384, ES512 (ECDSA), EdDSA (Ed25519/Ed448) ile imzalanmış token'ları ve imzasız (alg:none) token'ları doğru şekilde okur. Yalnızca signature doğrulaması algoritmaya özgüdür ve bu araç doğrulama yapmaz.
JWT'leri localStorage'da mı yoksa çerezde mi saklamalıyım?
Oturum token'ları için HttpOnly, Secure, SameSite=Strict çerezleri tercih edin. localStorage'daki bir token, sayfada çalışan herhangi bir JavaScript tarafından okunabilir; dolayısıyla tek bir XSS açığı tüm aktif oturumları sızdırır. HttpOnly çerezler JavaScript'e görünmez; bu da XSS'in zarar yarıçapını saldırganın canlı bir sayfa içinde yapabilecekleriyle sınırlar — günlerce yeniden oynatabileceği çalınmış bir token'la değil. localStorage kullanmak zorundaysanız (örneğin etki alanlar arası uygulamalarda), erişim token'ı ömürlerini kısa tutun (saat değil dakika düzeyinde) ve ayrı bir refresh token'ı HttpOnly çerezde tutun.
Node.js, Python veya Go'da bir JWT'yi nasıl çözerim?
Node.js: salt okuma için jsonwebtoken.decode(token), doğrulama için jsonwebtoken.verify(token, key). Python: okumak için PyJWT.decode(token, options={'verify_signature': False}), doğrulamak için bir anahtar geçirin. Go: salt okuma için jwt.ParseUnverified(token, claims), doğrulama için jwt.Parse(token, keyFunc). Hiçbir dilde üretim kodunda options={'verify_signature': False} ile doğrulama yapmayın — bu web aracının hata ayıklama amacıyla bilinçli olarak yaptığı şeydir ve yalnızca incelerken güvenlidir, kimlik doğrularken değil.
Bir JWT'nin azami boyutu nedir?
JWT standardı katı bir sınır koymaz, ancak çoğu web sunucusunda header'lar varsayılan olarak yaklaşık 8 KB ile sınırlıdır. Token'larınızı Authorization header'larına ve çerezlere rahatça sığsın diye 4 KB'nin altında tutun. Token'ınız bundan büyükse büyük olasılıkla payload'a fazla claim koyuyorsunuz — hacimli veriyi opak bir oturum kimliğinin arkasına alın ve gerektiğinde backend'inizden çekin. Şişkin JWT'ler her API çağrısıyla gönderildiklerinden her istekte de pahalıya patlar.
Token'ımı yapıştırdım ve "Geçersiz JWT formatı" aldım — sorun ne?
Geçerli bir JWT, noktayla ayrılmış tam olarak üç parçadan oluşur: header.payload.signature. Yaygın nedenler: (1) yanlışlıkla yalnızca payload segmentini kopyaladınız, (2) ortaya boşluk veya satır sonu yapıştı, (3) token taşınırken kesildi (terminal sarmalaması bunda yaygındır), (4) token aslında bir JWE'dir ve formatı header.encryptedKey.iv.ciphertext.tag (beş segment) şeklindedir, ya da (5) token URL ile kodlanmıştır ve önce URL'den çözmeniz gerekir. API'nizin döndürdüğü ham değeri kontrol edin — çoğu editör üzerine gelindiğinde görünmez karakterleri gösterir.
Bir JWT'yi gizli anahtar olmadan çözebilir miyim?
Evet — header ve payload Base64URL ile kodlanmıştır, şifrelenmemiştir. Token'a sahip olan herkes claim'leri herhangi bir anahtar olmadan okuyabilir. Bu, tasarımın bir parçasıdır: payload, alıcının buradan yetkilendirme kararları verebilmesi için okunabilir olacak şekilde tasarlanmıştır. Gizli anahtar veya açık anahtar yalnızca token'ın değiştirilmediğini doğrulamak için gereklidir. Bu yüzden bir JWT payload'ının içine asla hassas veri (parolalar, özel anahtarlar, alıcının zaten bilmediği PII) koymamalısınız.
JWT'im Postman'de çalışıyor ama backend reddediyor — nasıl hata ayıklarım?
Token'ı burada çözün ve şunları kontrol edin: (1) exp — sunucunun saatine göre gelecekte mi? Sunucu saat farkı sık görülen bir suçludur. (2) iss / aud — backend'inizin beklediğiyle birebir eşleşiyorlar mı? aud uyumsuzluğu en sık görülen yanlış-negatiftir. (3) alg — doğrulama kodunuz bu algoritmaya izin veriyor mu? Yalnızca RS256 için yapılandırılmış bir kütüphanede HS256 token'ı düşer. (4) kid — anahtar rotasyonu kullanıyorsanız, header'daki key ID JWKS'inizde mevcut mu? (5) signature — doğru gizli anahtarı/açık anahtarı yapıştırdınız mı? Bu çözücü; (1), (2), (3) ve (4)'ü header ve payload görünümlerinde öne çıkarır, böylece bunları hızla eleyebilirsiniz.