logo
GeekFormat

JWT Aracı

Encoded Token172 chars2026-07 tarihinde güncellendi
header
payload
signature
Valid JWTHS256
Secret38 chars
Header
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}
Claims details4 items
sub· Konu1234567890
name· NameJohn Doe
admin· Admintrue
iat· Verilme zamanı151623902218.01.2018 09:30:22
Header details2 items
algHS256HMAC (simetrik)
typ· TypeJWT
All operations run locally in your browser; the Token and key are never sent to any server.

Ücretsiz online JWT decode, doğrulama ve oluşturma aracı. Header, Payload ve imza bilgilerini görüntüleyin, API kimlik doğrulama debugging için idealdir.

İlgili Öneriler

Kullanım senaryoları

  • JWT'yi çevrimiçi decode etme: OAuth 2.0 / OIDC giriş hata ayıklaması sırasında tokenı hızlıca ayırarak Header algoritmasını ve Payload Claims'lerini incelemek
  • JWT imzalarını doğrulama: gerçek zamanlı olarak token imzalarını doğrulamak için bir Secret / genel anahtar kullanın ve 401'in 'kötü imza', 'süresi dolmuş' veya 'algoritma uyuşmazlığı' olup olmadığına karar verin
  • Entegrasyon sırasında test JWT'leri üretme: token üretmek için backend kodunu geçici olarak değiştirmenize gerek kalmadan, tarayıcıda bir test anahtar çiftiyle JWT yayınlayın
  • PEM ↔ JWK dönüşümü: OIDC IdP size JWK verdi ama sunucu PEM istiyor (veya tam tersi) — OpenSSL betiği yazmak yerine yerinde dönüştürün
  • 401 Unauthorized'ı teşhis etme: süreyi, alg-ağ geçidi eşleşmesini, anahtar eşleşmesini ve PEM formatlamasını adım adım kontrol edin
  • RS256 ile PS256'yı karşılaştırma: birçok OIDC sağlayıcısı varsayılan olarak RS256 kullanırken AWS SigV4 PS256'yı tercih eder — aynı RSA anahtar çiftiyle algoritmaları değiştirin ve sonuçları karşılaştırın
  • JWT iç mekanizmasını öğrenme: alg'ı değiştirin, Payload'ı düzenleyin, tarayıcıda anahtarı değiştirin ve imzanın gerçek zamanlı olarak nasıl kırıldığını izleyin — RFC okumaktan çok daha hızlı

Özellikler

  • Tek yerde Decode + Doğrulama + Üretim: bir token yapıştırarak Header/Payload/Signature'ı ayırın, imzayı doğrulamak için algoritma ve anahtarı değiştirin, yeni bir token üretmek için Claims'leri düzenleyip yeniden imzalayın — tam JWT sorun giderme zincirini kapsar
  • 13 algoritmanın tümü desteklenir: HS256/HS384/HS512 (HMAC), RS256/RS384/RS512 (RSA-PKCS1-v1_5), ES256/ES384/ES512 (ECDSA), PS256/PS384/PS512 (RSA-PSS), EdDSA — OAuth 2.0, OIDC, JWS, API ağ geçitleri ve kurumsal SSO'yu kapsar
  • PEM ve JWK formatları: RSA, ECDSA ve Ed25519 anahtarları PEM dizelerini (-----BEGIN PUBLIC KEY----- başlıklarıyla) ve JWK JSON'ını (kid/kty/n/e alanları) kabul eder — OIDC /.well-known/jwks.json çıktısını doğrudan yapıştırın
  • Çoklu HMAC Secret girişi biçimleri: ham UTF-8 dizesi, hex baytlar veya Base64/Base64URL kodlanmış — tek tıklamayla değiştirin, böylece 'aynı görünüyor ama imza başarısız oluyor' asla olmaz
  • Otomatik anahtar çifti üretimi: RSA-2048, RSA-4096, P-256, P-384 ve Ed25519 anahtar çiftleri tarayıcıda üretilir, anında test kullanımı için PEM ve JWK formatlarında sunulur
  • Claims'lerin anlamsal vurgulanması: exp / iat / nbf otomatik olarak okunabilir zamana dönüştürülür, süresi dolmuş / henüz-geçerli-değil / yayımlandı durumu vurgulanır; Header'daki alg / typ / kid bireysel olarak etiketlenir
  • %100 istemci tarafında, sıfır yükleme: her parse, doğrulama ve imzalama tarayıcının yerel Web Crypto API'si üzerinden çalışır — tokenlar, anahtarlar ve payload asla tarayıcıdan ayrılmaz, 'üretim tokenlarını asla rastgele çevrimiçi araçlara yapıştırma' güvenlik ilkesine uygun
  • Tek tıklamayla kopyalama: Header, Payload, Signature ve yeni üretilen token bağımsız olarak kopyalanabilir; dokümantasyon, ticket ve curl komutları için

Nasıl Kullanılır

  1. Tokenı yapıştırın veya girin: JWT dizesini giriş alanına yerleştirin; araç otomatik olarak Header, Payload ve Signature'ı ayırır ve her birini biçimlendirilmiş JSON olarak görüntüler
  2. Algoritmayı seçin: HS256 / RS256 / ES256 / PS256 / EdDSA arasında geçiş yapın; araç Header.alg'dan çıkarır ve herhangi bir uyuşmazlığı işaretler
  3. Bir anahtar içe aktarın: bir HMAC Secret'ı, PEM dizesi veya JWK JSON'u yapıştırın; asimetrik algoritmalar için hemen bir test anahtarı almak üzere 'Anahtar çifti üret'e tıklayın
  4. Doğrulayın veya yeniden imzalayın: Decode modunda genel anahtarla doğrulayın ve '✅ imza geçerli / ❌ imza geçersiz'i görün; Encode modunda Claims'leri düzenleyin ve yeni bir token üretmek için özel anahtarla imzalayın

Sık Sorulan Sorular

JWT'nin üç bölümü nelerdir?

Bir JWT dizesi `Header.Payload.Signature` biçimindedir, her segment Base64URL ile kodlanmıştır. Header algoritmayı (HS256, RS256 gibi) ve token türünü (typ: JWT) bildirir; Payload kullanıcı Claims'lerini (beyanları) taşır, yaygın alanlar sub (kullanıcı ID), iat (yayımlanma zamanı), exp (sona erme zamanı), nbf (not-before), aud (hedef kitle), iss (verendir); Signature ilk iki segmentin bir anahtarla imzalanmasının sonucudur, amaç 'kurcalama tespiti'dir, 'sızıntı önleme' değil.

Decode ettikten sonra Payload'ı düzenleyebilir miyim?

Görüntüleyebilir ve düzenleyebilirsiniz ama **taklit edemezsiniz**. Header veya Payload'ı değiştirdiğiniz anda, orijinal Signature geçersiz olur ve sunucu doğrulamayı reddeder. Değiştirilmiş tokenı tekrar geçerli kılmak için, aynı algoritma ve aynı anahtarla **yeniden imzalamanız** gerekir — tam da bu yüzden bu araç tek yerde 'decode + düzenle + üret' sunar: görüntülemek için decode edin, değiştirin ve hemen test için yeni bir token üretin, böylece her seferinde backend'den token yayımlamak için kodu geçici olarak değiştirmesini istemeniz gerekmez.

HS256, RS256, ES256, PS256 ve EdDSA arasındaki fark nedir?

HS256 paylaşımlı Secret ile HMAC kullanır (simetrik), hızlıdır ama secret yönetimi kritiktir. RS256 RSA özel/genel anahtarları kullanır (asimetrik), veren özel anahtarla imzalar, doğrulayıcı genel anahtarı kullanır. ES256 eliptik eğrili ECDSA kullanır (P-256), daha kısa imza. PS256 RSA-PSS kullanır, RS256'dan daha güvenlidir. EdDSA (genellikle Ed25519) hızlı ve deterministiktir, OAuth 2.1 için önerilir.

JWT'im neden sürekli 'Invalid Signature' gösteriyor?

Genellikle anahtar, Secret biçimi, algoritma veya Base64URL kodlaması tam olarak eşleşmediği içindir. Fazladan bir boşluk, yanlış bir PEM yeni satırı veya Base64 ile Base64URL karışıklığı yeterlidir. Bayt bayt eşleşmeyi kontrol edin ve Header.alg'nin seçilen algoritmayla eşleştiğini doğrulayın.

Aynı RSA anahtarı RS256 ve PS256'yı çapraz doğrulayabilir mi?

Hayır. RS256 RSASSA-PKCS1-v1_5 kullanır, PS256 RSA-PSS kullanır. Aynı RSA anahtarıyla bile çapraz doğrulama yapamazlar. İmzalayan ve doğrulayıcı aynı algoritmayı kullanmalıdır.

alg:none saldırısı nedir?

Bir saldırgan Header'ı `{"alg":"none"}` (imza yok) olarak değiştirir veya RS256'yı HS256 ile değiştirir (genel anahtarı bir HMAC Secret'ı gibi kullanarak). Sunucu bir algoritma beyaz listesi zorunlu kılmalı ve tokenın hangi algoritmayı kullanacağına asla karar vermesine izin vermemelidir.

PEM ve JWK arasında nasıl dönüştürürüm?

PEM, BEGIN/END satırlarıyla klasik OpenSSL notasyonudur. JWK JSON'dur ve OAuth/OIDC'de yaygındır. OIDC sağlayıcıları genellikle genel anahtarları `/.well-known/jwks.json` üzerinden yayınlar. Bu araç PEM ve JWK biçimlerini doğrudan işleyebilir.

Tarayıcı JWT imzalarını doğrudan doğrulayabilir mi?

Evet. Tarayıcının yerel Web Crypto API'si (`window.crypto.subtle`) üçüncü taraf kütüphaneler olmadan HMAC, RSA, ECDSA, RSA-PSS ve Ed25519 imzalama ve doğrulamasını destekler. Bu araç her doğrulama için ön uçta `crypto.subtle.importKey` ve `crypto.subtle.verify` kullanır, bu yüzden tokenlarınızı veya anahtarlarınızı asla göndermez. Not: Web Crypto yalnızca güvenli bağlamlarda kullanılabilir: **HTTPS** veya `localhost`.

Tokenım bir sunucuya gönderiliyor mu?

Hayır. Bu araçtaki tüm parse, doğrulama ve imzalama yerel Web Crypto API üzerinden tarayıcıda çalışır. Token, Header, Payload, Signature, secret / özel anahtar ve üretilen herhangi bir anahtar çifti asla bir sunucuya gönderilmez. Tarayıcınızın DevTools Network sekmesini açın ve token içeriği taşıyan herhangi bir giden istek görmezsiniz. Sayfa yüklendikten sonra çevrimdışı kullanılabilir.

JWT hassas kullanıcı bilgileri için güvenli bir yer mi?

**Hayır.** JWT Payload'ı varsayılan olarak düz metindir — tokena sahip olan herkes Base64URL ile decode edip içeriği okuyabilir. Şifreleme yoktur. **Asla** parolaları, ulusal kimlik numaralarını, kredi kartı numaralarını, API anahtarlarını, erişim tokenlarını veya yenileme tokenlarını bir JWT'ye düz metin olarak koymayın. Şifrelemeye ihtiyacınız varsa, JWS yerine JWE (RFC 7516) kullanın. JWT'ler hassas olmayan Claims'ler (kullanıcı ID, rol, sona erme, kiracı ID) için uygundur; hassas veriler sunucu tarafında `sub` kullanılarak sorgulanmalıdır.

JWT Decode, Doğrulama ve Üretim Nedir?

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.

Code Examples

50 lines of Node.js: hand-written HS256 sign and verify

javascript

Distills JWT's core mechanism: encode Header and Payload in Base64URL, then HMAC-SHA256 the `header.payload` string. In production, use a library like jsonwebtoken or jose — this snippet exists to make signature failures debuggable.

const crypto = require('node:crypto')

function b64url(input) {
  return Buffer.from(input)
    .toString('base64')
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '')
}

function hmacSign(data, secret) {
  return b64url(crypto.createHmac('sha256', secret).update(data).digest())
}

function sign(payload, secret) {
  const header = b64url(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
  const body = b64url(JSON.stringify(payload))
  const signature = hmacSign(`${header}.${body}`, secret)
  return `${header}.${body}.${signature}`
}

function verify(token, secret) {
  const [h, p, s] = token.split('.')
  const expected = hmacSign(`${h}.${p}`, secret)
  const a = Buffer.from(s)
  const b = Buffer.from(expected)
  return a.length === b.length && crypto.timingSafeEqual(a, b)
}

const SECRET = 'my-super-secret-key'
const payload = { userId: 42, role: 'admin', exp: Math.floor(Date.now() / 1000) + 3600 }
const token = sign(payload, SECRET)

console.log(token)
console.log(verify(token, SECRET))       // true
console.log(verify(token, 'wrong-key'))  // false

Browser-side: Web Crypto API for HMAC signing

html

The core idea of this tool's front-end: use the browser's native crypto.subtle for HMAC, RSA, ECDSA, RSA-PSS and Ed25519 verification — no third-party library needed. Drop this into any HTML page to mint HS256 tokens.

<!doctype html>
<html>
  <body>
    <pre id="out"></pre>
    <script>
      const out = document.getElementById('out')

      const b64url = buf =>
        btoa(String.fromCharCode(...new Uint8Array(buf)))
          .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

      const b64urlStr = str => b64url(new TextEncoder().encode(str))

      async function sign(payload, secret) {
        const header = b64urlStr(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
        const body = b64urlStr(JSON.stringify(payload))
        const data = new TextEncoder().encode(`${header}.${body}`)

        const key = await crypto.subtle.importKey(
          'raw',
          new TextEncoder().encode(secret),
          { name: 'HMAC', hash: 'SHA-256' },
          false,
          ['sign']
        )

        const sig = await crypto.subtle.sign('HMAC', key, data)
        return `${header}.${body}.${b64url(sig)}`
      }

      ;(async () => {
        const token = await sign({ user: 'alice', role: 'admin' }, 'browser-demo-secret')
        out.textContent = token
      })()
    </script>
  </body>
</html>

Node.js: verify RS256 with jose (the right way)

javascript

Use a mature library like jose, jsonwebtoken, or PyJWT in production — never roll your own. This snippet shows how jose verifies an RS256 token, prints the failure reason on error (alg mismatch, bad signature, expired, kid not found, etc).

import { jwtVerify, importSPKI } from 'jose'
import { readFile } from 'node:fs/promises'

const token = 'eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.payload.signature'
const publicKeyPem = await readFile('public.pem', 'utf8')

try {
  const { payload, protectedHeader } = await jwtVerify(
    token,
    await importSPKI(publicKeyPem, 'RS256'),
    {
      issuer: 'https://idp.example.com',
      audience: 'my-app',
      algorithms: ['RS256'],     // critical: algorithm whitelist blocks alg:none and HS256-substitution attacks
    }
  )
  console.log('alg =', protectedHeader.alg)
  console.log('sub  =', payload.sub)
} catch (err) {
  console.error('verify failed:', err.code, err.message)
  // common: ERR_JWT_EXPIRED / ERR_JWS_INVALID / ERR_JWS_SIGNATURE_VERIFICATION_FAILED
}

Python: parse a token and print its Claims with PyJWT

python

The most common way to debug JWT on the Python side. PyJWT's decode() validates exp / nbf / iat by default and returns the result as a plain dict.

import jwt

token = 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxw'

# Parse (no signature check, just look at Header and Payload)
print(jwt.get_unverified_header(token))
# {'alg': 'HS256', 'typ': 'JWT'}

print(jwt.decode(token, options={'verify_signature': False}))
# {'sub': '1234'}

# Full verification
claims = jwt.decode(
    token,
    'my-super-secret-key',
    algorithms=['HS256'],
    audience='my-app',
    issuer='my-service',
)
print(claims['sub'])

Supported Video Formats

FormatMIMEBrowser supportWhen to use
HS256 / HS384 / HS512HMAC + SHA-256/384/512UniversalSimetrik anahtarlı algoritma: aynı Secret hem imzalar hem doğrular. Basit ve hızlıdır; güvenilen sınır içindeki servis kümeleri için uygundur. Secret, HS256 için en az 32 bayt, HS384 için 48 bayt, HS512 için 64 bayt olmalıdır.
RS256 / RS384 / RS512RSASSA-PKCS1-v1_5 + SHA-2Web Crypto APIEn yaygın asimetrik algoritmadır. Özel anahtarla imzalanır, açık anahtarla doğrulanır. Çoğu OIDC sağlayıcısı, API gateway ve kurumsal SSO akışında varsayılan tercihtir.
PS256 / PS384 / PS512RSA-PSS + SHA-2Web Crypto APIRSA-PSS, RS256’nın daha güncel ve daha güvenli alternatifidir. AWS SigV4, AWS Cognito ve modern OIDC sağlayıcıları genellikle bunu tercih eder. Doğrulamanın tutması için saltLength açıkça ayarlanmalıdır.
ES256 / ES384 / ES512ECDSA + P-256/P-384/P-521Web Crypto APIEliptik eğri imzalarıdır. Kısa imza üretir (ES256 yalnızca 64 bayt), hızlıdır ve JWT boyutunu küçültür. Sign in with Apple varsayılan olarak ES256 kullanır.
EdDSA (Ed25519)Ed25519 / Ed448Web Crypto APIYeni nesil, yüksek performanslı imza algoritmasıdır. İmzalar deterministiktir (aynı mesaj + aynı anahtar = aynı imza), nonce tekrar kullanımı riski yoktur ve yeni protokoller için güçlü bir seçenektir.

Output Example

A real MP3 file encoded to a Data URI — copy-ready:

Header (Base64URL): eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload (Base64URL): eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzE2MjM5MDIyfQ
Signature: kZJfaYjK3iCkVFL5EL9zGRZ5SmD8_x2h6B5c7pVFfVGo

Privacy & Security

Bu JWT çalışma alanı, tarayıcının yerel Web Crypto API'si tarafından desteklenen %100 tarayıcınızda çalışır. Yapıştırdığınız token, Header, Payload, Signature, HMAC Secret, herhangi bir RSA/ECDSA özel anahtarı, üretilen herhangi bir anahtar çifti ve her imza/doğrulama hesaplaması cihazınızda kalır — asla bir sunucuya gitmezler, asla loglanmazlar, asla analiz edilmezler ve asla önbelleğe alınmazlar. Sayfa yüklendikten sonra çevrimdışı kullanılabilir. En iyi uygulama: uzun ömürlü üretim tokenlarını veya üretim özel anahtarlarını bu dahil herhangi bir çevrimiçi araca asla yapıştırmayın. Bu araç hata ayıklama, entegrasyon testi, öğrenme ve test token üretimi için uygundur — üretim secret'ları ve özel anahtarlar kontrollü, yerel bir ortamda işlenmelidir.

Authoritative References

Troubleshooting

Invalid Signature: 'signature is invalid'

Token ve doğrulama anahtarı eşleşmiyor. Yaygın nedenler: (1) sunucunun anahtarı ve araca yapıştırdığınız anahtar farklı (en yaygın); (2) anahtar görünmez karakterler içeriyor (sondaki boşluk, yeni satır, sıfır genişlikli karakter); (3) Base64 ve Base64URL karıştırılmış; (4) yanlış algoritma seçilmiş (Header HS256 diyor, sunucu RS256 olarak doğruluyor veya tam tersi). Önce anahtarın bayt bayt eşleşip eşleşmediğini kontrol edin: PEM'in sonundaki yeni satırlara, HMAC Secret'ının sonundaki boşluklara ve URL tarafından yanlış decode edilmiş olabilecek JWK `k` değerlerine dikkat edin. Araçtaki algoritmanın tokenın Header.alg'si ile eşleştiğini doğrulayın. Tam hatayı yeniden üretmek ve 'decode başarılı' ile 'doğrulama başarısız' arasında gerçekleştiğini onaylamak için bu aracın decode-plus-verify'sini kullanın.

HTTP 401 Unauthorized: Token Expired veya iat gelecekte

İmza doğrulaması geçti ama `exp` geçmişte (Token Expired), `nbf` hala gelecekte (Not Before) veya `iat` sunucunun mevcut zamanından sonra (sıklıkla saat senkronizasyon kayması nedeniyle). Başka bir yaygın durum, eşleşmeyen `aud` (hedef kitle): token Uygulama A için yayımlandı ama Uygulama B tarafından doğrulanıyor. exp / nbf / iat durumunu bir bakışta görmek için bu araçtaki vurgulanan Claims alanını kullanın. Kırmızı exp = süresi dolmuş, yeniden yayınlayın. Kırmızı nbf = henüz geçerli değil, iat'ın gelecekteki bir zaman olup olmadığını kontrol edin. Kırmızı aud = yanlış hedef kitle, sunucunun doğru hedef kitleyle yapılandırılıp yapılandırılmadığını kontrol edin.

PEM veya JWK içe aktarma hatası

PEM'in fazladan boş satırları var veya başlık/altbilgi işaretçileri eksik (`-----BEGIN PUBLIC KEY-----`); JWK'te zorunlu alanlar eksik (`kty` / `n` / `e` / `kid`); JWK `k` değeri Base64URL padding'inden yoksun (`=` ile doldurulmalı veya katı bir şekilde `=` olmadan); bir RSA özel anahtarı genel anahtar olarak içe aktarılıyor; bir Ed25519 özel anahtarı (32 baytlık seed) 64 bayt olarak sağlanıyor. `openssl rsa -in key.pem -pubout -outform PEM` veya `openssl ec -in key.pem -pubout` ile standart bir PKIX PEM'i yeniden dışa aktarın; JWK için elle kodlamak yerine OIDC Discovery uç noktası `/.well-known/jwks.json`'dan ham çıktıyı kullanın. Bu araç PEM başlıklarını, eksik padding'i ve eksik JWK alanlarını otomatik olarak algılar ve bir ipucu verir.

RS256 ile PS256 arasında diller arası imza hataları

RS256 RSASSA-PKCS1-v1_5 kullanır, PS256 RSA-PSS kullanır. İkisi **çapraz doğrulama yapamaz** — belirli bir RSA anahtarıyla RS256 ile imzalanmış bir token her zaman PS256 doğrulamasını başarısız eder ve imza birkaç bayt uzunlukta farklılık gösterebilir. İmzalayan ve doğrulayanın aynı algoritmayı kullandığından emin olun. AWS SigV4 PS256 kullanır, çoğu OIDC IdP RS256 kullanır. RSA-PSS ayrıca bir `saltLength` parametresine sahiptir — OpenSSL varsayılanı 32, jose varsayılanı 32, Go'nun `rsa.PSSOptions{SaltLength: rsa.PSSSaltLengthEqualsHash}` doğru eşdeğeridir. Diller arası entegrasyon testinden önce bunu sabitleyin.

alg:none saldırısı ve HS256 anahtar değiştirme saldırısı

Sunucu, tokenın Header'ında beyan edilen alg'a göre bir doğrulama algoritması seçer. Bir saldırgan başlığı `alg: none` (imza yok) olarak yeniden yazar veya bir RS256 tokenını HS256'ya yeniden yazar (genel anahtarı paylaşımlı bir HMAC Secret'ı gibi kullanarak) ve doğrulamayı atlatır. CVE-2015-9235 (jsonwebtoken) ve CVE-2022-23529 (birden fazla Node kütüphanesi) gibi tarihi CVE'ler bu kalıba dayanır. Sunucu bir algoritma beyaz listesi zorunlu kılmalıdır — örneğin `algorithms: ['RS256']` — ve tokenın hangi algoritmayı kullanacağına asla karar vermesine izin vermemelidir. Bu aracın UI'si hem Header.alg'yi hem de gerçekten seçtiğiniz algoritmayı gösterir ve uyuşmazlıkları işaretler: bu, 'istemci Header.alg'ye güvenmemelidir'in canlı bir demosudur.