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

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.

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ı

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

Output Example

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

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

Ö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

Kod Örnekleri

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'])

5 JWT imza algoritması sınıfı karşılaştırması: hangisini seçmeli?

JWT tek bir algoritma değildir — 5 algoritma ailesi anahtar, performans, güvenlik ve uyumluluk açısından farklı ödünleşimler sunar. Önce senaryoyu değerlendirip sonra algoritmayı seçmek birçok sorundan kurtarır.

AlgoritmaTürAnahtarPerformansTipik senaryolarDikkat edilmesi gerekenler
HS256HMAC simetrikAynı SecretÇok hızlıServis kümesi içinde, güvenilir ortam, monolitik uygulamaSecret doğrulayana sızmamalı; en az 32 rastgele bayt
RS256RSA asimetrikÖzel anahtar imzalar / genel anahtar doğrularOrtaOIDC, API ağ geçitleri, kurumsal SSO, genel/özel anahtar ayrımı gerektiğindeRSASSA-PKCS1-v1_5 kullanır; diller arası padding sabitlenmelidir
PS256RSA-PSS asimetrikÖzel anahtar imzalar / genel anahtar doğrularOrtaAWS SigV4, AWS Cognito, yeni nesil OIDC IdP'lerisaltLength açıkça sabitlenmelidir (OpenSSL/jose=32, Go=karekök uzunluğu)
ES256ECDSA asimetrikÖzel anahtar imzalar / genel anahtar doğrularHızlı + kısa imzaApple Sign in with Apple, mobil, düşük bant genişliğiFarklı eğriler (P-256/P-384/P-521) sunucuyla eşleşmelidir
EdDSAEd25519/Ed448Özel anahtar imzalar / genel anahtar doğrularÇok hızlı (deterministik imza)OAuth 2.1, yeni protokoller, yüksek frekanslı doğrulamaWeb Crypto Ed25519'ı destekler; Ed448 henüz tüm platformlarda etkin değil

Best Practices

Production Secret / özel anahtarını asla herhangi bir çevrimiçi araca yapıştırmayın

Bu araç %100 tarayıcıda yerel olarak işlem yapsa da (hiçbir token veya anahtarı yüklemez), bir kez yerleşen hata ayıklama akışı, sonradan üretimdeki uzun ömürlü Secret / özel anahtar / Access Token'ın yanlışlıkla bilinmeyen bir çevrimiçi araca yapıştırılmasına ya da ekran görüntüsüyle sızmasına yol açabilir. Uzun ömürlü tokenlar (Refresh Token, üretim özel anahtarı, API Anahtarı) kontrollü yerel ortamda işlenmelidir; bu araç yalnızca kısa süreli Access Token'ları hata ayıklamak, entegrasyon için test anahtar çiftleri oluşturmak ve JWT yapısını öğrenmek içindir.

OWASP JSON Web Token Cheat Sheet

Sunucu algoritma beyaz listesi uygulamalı, asla Token'ın Header.alg değerine güvenmemelidir

alg: none saldırısı (CVE-2015-9235 vb.) ve HS256 ikame saldırısı (RSA sunucusunu kandırmak için genel anahtarı Secret olarak kullanmak) sunucunun Header'da bildirilen algoritmaya göre doğrulama mantığını seçmesinden kaynaklanır. Üretim kodu, algorithms beyaz listesini sabit kodlamalıdır, örneğin `algorithms: ['RS256']`; tokenın hangi algoritmayı kullanacağına asla karar vermesine izin verilmemelidir. Hata ayıklama sırasında Header.alg sunucunun beklentisiyle eşleşmiyorsa, önce sunucu yapılandırmasından şüphelenin, token içeriğinden değil.

HS256 Secret'ı en az 32 baylık rastgele bir sayı olmalıdır

HS256 HMAC-SHA256 kullanır; anahtar uzunluğu özet uzunluğundan (32 bayt) kısa olursa kaba kuvvet deneme maliyetini önemli ölçüde düşürür. 'my-secret', 'password123' gibi kısa dizeler kullanmayın, servis adı/şirket adı/yıl birleştirmeyin. Standart yol: `openssl rand -base64 32` veya `crypto.randomBytes(32).toString('base64url')` ile üretin, ortam değişkenlerinde / KMS / anahtar yönetim servisinde saklayın, asla koda yazmayın.

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

Üretim JWT'si sadece imzayı değil exp / nbf / iat / iss / aud değerlerini de doğrulamalıdır

İmzanın geçmesi yalnızca 'tahrif edilmediğini' kanıtlar, 'süresi dolmadığını', 'gerçekten bu IdP tarafından imzalandığını' ve 'gerçekten bu uygulama için imzalandığını' kanıtlamaz. Üretim ortamı zorunlu olarak exp (süre sonu), nbf (geçerlilik başlangıcı), iat (imzalanma zamanı), iss (imzalayan) ve aud (hedef kitle) dahil ilgili tüm Claim'leri doğrulamalıdır; hiçbiri atlanmamalıdır. OWASP bu 4-5 öğeyi açıkça zorunlu kılar. Yalnızca imzayı doğrulayıp süreyi kontrol etmemek, birçok token sızıntısı olayının (süresi hiç dolmayan refresh token) kök nedenidir.

Token süre sonu katmanlama: Access 15-30 dakika, Refresh 7-30 gün

Access Token API çağrılarından sorumludur; süre sonu ne kadar kısa olursa o kadar güvenli olur (sızdıktan sonra çabuk geçersiz olur); Refresh Token Access Token değişiminden sorumludur, daha uzun olabilir ancak sunucuda saklanmalı ve iptal edilebilir olmalıdır. Yaygın deneyim değerleri: Access 15-30 dakika, Refresh 7-30 gün; Refresh Token Rotation (her Refresh ile Access değiştirilirken aynı anda yeni bir Refresh de üretilir, eski Refresh anında geçersiz olur) ile birlikte kullanıldığında sızıntı tespiti ile kullanıcı deneyimi arasında denge sağlar.

Durumsuz vs durumlu kimlik doğrulama: JWT, Session'ın yerini tutmaz

JWT durumu tokenın içine paketler; mikroservis yatay ölçekleme ve CORS çapraz alan senaryolarını doğal olarak destekler, ancak iptal maliyeti yüksektir (kara liste veya kısa süre sonu gerekir). Session durumu sunucudaki Redis/DB'ye depolar, 'kullanıcıyı atabilir' ancak paylaşılan depolama gerektirir. **İkisi arasında seçim yapmak gibi değil**: kısa süreli Access JWT + sunucu tarafı Refresh Token oturum kaydı, durumsuz ölçekleme ve anlık iptali bir arada sunan en yaygın hibrit çözümdür. Finans/devlet gibi anlık iptal gerektiren çekirdek sistemlerde salt JWT kullanımına dikkat edin.

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

Payload varsayılan olarak düz metindir, hassas verileri JWT'ye sıkıştırmayın

JWT (JWS) varsayılan olarak Payload'ı şifrelemez; tokenı olan herkes Base64URL ile çözüp içeriği okuyabilir. **Kesinlikle** parolaları, ulusal kimlik numaralarını, kredi kartı numaralarını, API anahtarlarını, Access Token'ı veya Refresh Token'ı Payload'a koymayın. JWT, hassas olmayan Claim'ler (kullanıcı ID, rol, süre sonu, kiracı ID) için uygundur; hassas veriler sunucu tarafından sub üzerinden sorgulanmalıdır. Payload şifrelemesi gerektiğinde JWE (RFC 7516) kullanın, ancak 2-5 kat daha yavaştır ve anahtar yönetimi karmaşıklığı ekler — 'hassas olmayan Claim + sunucu sorgusu' modelini tercih edin.

JWT nedir?

RSA-PSS (PS256/PS384/PS512) diller arası entegrasyonda önce saltLength sabitlenmelidir

RS256 ve PS256 çapraz doğrulanamaz (farklı padding), PS256'nın bir başka tuzağı daha var: `saltLength` parametresi. OpenSSL varsayılanı 32 bayt, Node jose varsayılanı 32 bayt, Python PyJWT varsayılanı özet uzunluğuna eşit (SHA-256=32), Go varsayılanı `rsa.PSSSaltLengthEqualsHash`. Diller arası entegrasyonda aynı değeri önceden sabitleyin (önerilen 32 bayt), aksi takdirde aynı RSA anahtar çiftiyle imzalanan PS256 tokenı farklı dillerde doğrulamada başarısız olur.

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

Hata ayıklama akışı: test anahtar çiftleri kullanın, üretime dokunmayın

Entegrasyon veya yerel geliştirmede, önce her zaman yepyeni bir test anahtar çifti oluşturun (HS256 için rastgele Secret, RS256/ES256/EdDSA için araçla tek tıkla üretilen anahtar çifti); üretim IdP'sinin özel anahtarını veya şirket alan adının Secret'ını asla yeniden kullanmayın. Hata ayıklama bittiğinde veya yerel test tamamlandığında test anahtarlarını derhal imha edin. Bu aracın 'Anahtar çifti üret' özelliği tam da bu amaçla tasarlanmıştır: RSA-2048/4096, P-256/P-384, Ed25519 tek tıkla üretilir ve hemen kullanıma hazırdır, entegrasyon bittiğinde doğrudan atılır.

Entegrasyon sırasında test JWT'leri üretme

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.

Sorun Giderme

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.

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.

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.

Authoritative References