JWT Aracı
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "1234567890",
"name": "John Doe",
"admin": true,
"iat": 1516239022
}sub· Konu1234567890name· NameJohn Doeadmin· Admintrueiat· Verilme zamanı1516239022→ 18.01.2018 09:30:22algHS256HMAC (simetrik)typ· TypeJWTÜ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 HS256 imzalama için bir HMAC-SHA256 Secret'ı üretin
JWT HS256, HMAC artı Base64URL'dir — önce HMAC'ı öğrenin, sonra JWT'yi
JWT'nin dahili olarak kullandığı Base64URL kodlamasını anlayın
JWT'nin Header, Payload ve Signature'ının tümü Base64URL ile kodlanmıştır
Üç JWT segmentinin her birini Base64URL ile decode edin
Bir JWT'yi ayırdıktan sonra, düz metni okumak için segmentleri Base64URL ile decode edin
Payload'ı şifrelemeniz gerektiğinde JWE veya AES kullanın
JWT Payload'ı varsayılan olarak düz metindir; hassas payload'lar JWE / AES kullanmalıdır
HS256'nın üzerine inşa edildiği SHA-256 hash'ini anlayın
HS256, HMAC artı SHA-256'dır — önce SHA-256'yı anlayın
Az önce ürettiğiniz JWT ile API'nize doğrudan istek atın
Bir JWT'yi hata ayıkladıktan sonra, API'yi test etmek için Authorization: Bearer'a yapıştırın
Normal İfade Test Cihazı
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
- 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
- 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
- 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
- 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
javascriptDistills 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')) // falseBrowser-side: Web Crypto API for HMAC signing
htmlThe 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)
javascriptUse 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
pythonThe 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.
| Algoritma | Tür | Anahtar | Performans | Tipik senaryolar | Dikkat edilmesi gerekenler |
|---|---|---|---|---|---|
HS256 | HMAC simetrik | Aynı Secret | Çok hızlı | Servis kümesi içinde, güvenilir ortam, monolitik uygulama | Secret doğrulayana sızmamalı; en az 32 rastgele bayt |
RS256 | RSA asimetrik | Özel anahtar imzalar / genel anahtar doğrular | Orta | OIDC, API ağ geçitleri, kurumsal SSO, genel/özel anahtar ayrımı gerektiğinde | RSASSA-PKCS1-v1_5 kullanır; diller arası padding sabitlenmelidir |
PS256 | RSA-PSS asimetrik | Özel anahtar imzalar / genel anahtar doğrular | Orta | AWS SigV4, AWS Cognito, yeni nesil OIDC IdP'leri | saltLength açıkça sabitlenmelidir (OpenSSL/jose=32, Go=karekök uzunluğu) |
ES256 | ECDSA asimetrik | Özel anahtar imzalar / genel anahtar doğrular | Hızlı + kısa imza | Apple Sign in with Apple, mobil, düşük bant genişliği | Farklı eğriler (P-256/P-384/P-521) sunucuyla eşleşmelidir |
EdDSA | Ed25519/Ed448 | Özel anahtar imzalar / genel anahtar doğrular | Çok hızlı (deterministik imza) | OAuth 2.1, yeni protokoller, yüksek frekanslı doğrulama | Web 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 SheetSunucu 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 üretmeSı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
| Format | MIME | Browser support | When to use |
|---|---|---|---|
| HS256 / HS384 / HS512 | HMAC + SHA-256/384/512 | Universal | Simetrik 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 / RS512 | RSASSA-PKCS1-v1_5 + SHA-2 | Web Crypto API | En 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 / PS512 | RSA-PSS + SHA-2 | Web Crypto API | RSA-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 / ES512 | ECDSA + P-256/P-384/P-521 | Web Crypto API | Eliptik 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 / Ed448 | Web Crypto API | Yeni 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
- Güvenli Dize Karşılaştırma
- Binary Dönüştürme
- Sezar Şifresi
- Mors Kodu
- Hex Dönüştürme
- Videoyu Base64'e Çevir
- Base64'ten videoya
- Resmi Base64’e Dönüştür
- Base64'ten Resme
- Metin Base64'e Dönüştürme
- Base64 Metne Dönüştür
- Dosya Hash Doğrulayıcı
- Dosyayı Base64'e Dönüştür
- Base64 Dosyaya Dönüştür
- Ses → Base64
- Base64'ten Ses
- AES şifreleme ve çözme
- DES Şifreleme ve Şifre Çözme
- Base32 Kodlayıcı Çözücü
- Base58 kodlama ve kod çözme
- Base64 Kodlama
- Base64 Kod Çözme
- Base64 Karşılaştırma
- Base64 Bölme
- Base64 çok satırlı birleştirme
- Base64 Biçimlendirme
- Base64 Format Kontrolü
- Toplu Base64 Kodlama
- Base64 Toplu Kod Çözme
- Base64 Temizleme
- Base64 Padding İşleme
- Base64 Uzunluk İstatistikleri
- Base64 Onaltılığa Dönüştür
- Base64 DataURL Dönüştürücü
- Base64-Hex Dönüştürücü
- Base85 Kodlayıcı ve Kod Çözücü
- HMAC Oluşturucu ve Doğrulayıcı
- PBKDF2 Anahtar Türetme
- MD5 Özeti
- SHA-256 Özeti
- SHA1 Özeti
- SHA512 Özeti
- JWT Aracı
- HTML Encode/Decode
- Unicode Escape
- URL Kodlama
- URL Safe Base64
- MIME Base64
- Java Obfuscation
- JS Obfuscation
- PHP Obfuscation
- Python Obfuscation