JWT टूल

Encoded Token172 chars2026-07 में अपडेट किया गया
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· विषय1234567890
name· NameJohn Doe
admin· Admintrue
iat· जारी किया गया151623902218/01/2018, 09:30:22
Header details2 items
algHS256HMAC (सममित)
typ· TypeJWT
All operations run locally in your browser; the Token and key are never sent to any server.

JWT Token डिकोड, वेरिफाई और जनरेट ऑनलाइन करें। Header, Payload और सिग्नेचर इन्फॉर्मेशन व्यू करें, API ऑथेंटिकेशन डिबगिंग के लिए आदर्श।

संबंधित सुझाव

JWT HS256 साइनिंग के लिए HMAC-SHA256 Secret जनरेट करें

JWT HS256 HMAC प्लस Base64URL है — पहले HMAC सीखें, फिर JWT

वह Base64URL एन्कोडिंग समझें जो JWT आंतरिक रूप से उपयोग करता है

JWT का Header, Payload और Signature सभी Base64URL-एन्कोडेड हैं

तीन JWT सेगमेंट्स में से प्रत्येक को Base64URL में डिकोड करें

JWT को विभाजित करने के बाद, प्लेन-टेक्स्ट पढ़ने के लिए सेगमेंट्स को Base64URL में डिकोड करें

Payload को एन्क्रिप्ट करने की आवश्यकता होने पर JWE या AES का उपयोग करें

JWT Payload डिफॉल्ट रूप से प्लेन-टेक्स्ट होता है; संवेदनशील payload को JWE / AES का उपयोग करना चाहिए

वह SHA-256 हैश समझें जिस पर HS256 बना है

HS256 HMAC प्लस SHA-256 है — पहले SHA-256 समझें

अभी-अभी जनरेट किए गए JWT के साथ अपने API को सीधे हिट करें

JWT को डिबग करने के बाद, API को टेस्ट करने के लिए इसे Authorization: Bearer में पेस्ट करें

Regex टेस्टर

JWT डिकोड, वेरिफाई और जनरेट क्या है?

JWT (JSON Web Token) IETF द्वारा RFC 7519 में परिभाषित एक ओपन स्टैंडर्ड है (RFC 7515 JWS सिग्नेचर फॉर्म का वर्णन करता है, RFC 7516 JWE एन्क्रिप्शन का वर्णन करता है, RFC 7517 JWK कीज को परिभाषित करता है) HTTP अनुरोधों, OIDC फ्लो और माइक्रोसर्विस कॉल्स के बीच 'घोषित' उपयोगकर्ता जानकारी को सुरक्षित रूप से स्थानांतरित करने के लिए। एक मानक JWT स्ट्रिंग Base64URL-एन्कोडेड तीन सेगमेंट से बनी होती है: Header (एल्गोरिदम और प्रकार), Payload (Claims, उपयोगकर्ता डेटा) और Signature (पहले दो पर की-आधारित सिग्नेचर)। तीन सेगमेंट एक डॉट `.` से जुड़े होते हैं, उदा. `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`।

**JWT एन्क्रिप्शन नहीं है।** यह सबसे आम गलतफहमी है। Payload डिफॉल्ट रूप से प्लेन-टेक्स्ट होता है — कोई भी इसे Base64URL में डिकोड करके सामग्री पढ़ सकता है। JWT **टैम्परिंग डिटेक्शन** प्रदान करता है, गोपनीयता नहीं: सर्वर साझा की के साथ Header.Payload को फिर से साइन करता है और टोकन के Signature से तुलना करता है। यदि वे मेल खाते हैं, टोकन ट्रांजिट में बदला नहीं गया है। यह 'एंटी-काउंटरफिट स्टैम्प वाला ट्रेन टिकट' का रूपक है: निरीक्षक को इससे मतलब है कि टिकट असली है या नहीं, QR कोड पढ़ने योग्य है या नहीं इससे नहीं।

JWT 13 एल्गोरिदम के बीच जिम्मेदारियों को साफ तौर पर बांटता है। **HMAC परिवार** (HS256/HS384/HS512) साइनिंग और वेरिफिकेशन के लिए सममित की का उपयोग करता है, तेज और सरल, एक सेवा या विश्वसनीय क्लस्टर के लिए उपयुक्त; secret कम से कम digest की लंबाई का होना चाहिए (उदा. HS256 के लिए ≥ 32 बाइट्स)। **RSA परिवार** (RS256/RS384/RS512) सबसे आम असममित स्कीम RSASSA-PKCS1-v1_5 का उपयोग करता है — साइनर के पास प्राइवेट की होती है, वेरिफायर के पास पब्लिक की होती है। **RSA-PSS परिवार** (PS256/PS384/PS512) मजबूत सुरक्षा गारंटी के साथ नए RSA-PSS पैडिंग का उपयोग करता है, AWS SigV4 और आधुनिक OIDC आइडेंटिटी प्रोवाइडर द्वारा प्राथमिकता दी जाती है। **ECDSA परिवार** (ES256/ES384/ES512) छोटे सिग्नेचर और बेहतर प्रदर्शन के साथ एलिप्टिक कर्व्स (क्रमशः P-256/P-384/P-521) का उपयोग करता है। **EdDSA** (मुख्य रूप से Ed25519) बेहद तेज और नियतिवादी है (वही संदेश + वही की = हर बार वही सिग्नेचर) और OAuth 2.1 और नए प्रोटोकॉल में अनुशंसित एल्गोरिदम है।

सुरक्षा वह जगह है जहां JWT प्रोडक्शन में ठोकर खाता है। OWASP JWT Cheat Sheet कम से कम चार सख्त नियमों को सूचीबद्ध करता है: (1) Payload में कभी भी पासवर्ड, राष्ट्रीय पहचान दस्तावेज, कार्ड नंबर या API कीज को प्लेन-टेक्स्ट के रूप में न रखें; (2) सर्वर को **टोकन के Header में घोषित alg फील्ड पर कभी भरोसा नहीं करना चाहिए** — हार्ड-कोडेड एल्गोरिदम के साथ वेरिफाई करना चाहिए, अन्यथा `alg: none` में हेडर को फिर से लिखने वाला हमलावर सब कुछ बायपास कर देता है (यह CVE-2015-9235 जैसे ऐतिहासिक CVE का स्रोत है); (3) HMAC secrets यादृच्छिक होने चाहिए और कम से कम 32 बाइट्स लंबे होने चाहिए, कभी छोटी स्ट्रिंग्स नहीं; (4) वेरिफिकेशन केवल सिग्नेचर चेक्स से अधिक है — आपको `exp` (समाप्ति), `nbf` (not-before), `iss` (जारीकर्ता) और `aud` (दर्शक) को भी मान्य करना चाहिए। यह टूल इनमें से प्रत्येक Claims को UI में हाइलाइट करता है ताकि आप तुरंत बता सकें कि विफलता सिग्नेचर समस्या है, समय समस्या है या Claims समस्या है।

JWT सत्रों का विकल्प नहीं है। सत्रें उपयोगकर्ता की स्थिति को सर्वर पर संग्रहित करती हैं (Redis या डेटाबेस); JWT स्थिति को टोकन में पैक करता है। माइक्रोसर्विस आर्किटेक्चर, स्टेटलेस API, मोबाइल क्लाइंट और बहुत अधिक CORS वाले सेटअप JWT से लाभान्वित होते हैं; पारंपरिक एंटरप्राइज सिस्टम और तत्काल रद्दीकरण की आवश्यकता वाले फ्लो (उदा. 'इस उपयोगकर्ता को अभी निकालो') अभी भी सत्रों द्वारा बेहतर सेवा प्राप्त करते हैं। यह टूल शुद्ध JWT डिबगिंग के साथ-साथ सत्र से JWT माइग्रेशन के टोकन पार्स / सिग्नेचर वेरिफिकेशन / Payload एडिटिंग स्टेप्स को भी कवर करता है।

उपयोग के मामले

  • JWT को ऑनलाइन डिकोड करें: OAuth 2.0 / OIDC लॉगिन डिबगिंग के दौरान टोकन को तेजी से अलग करके Header एल्गोरिदम और Payload Claims की जाँच करें
  • JWT सिग्नेचर वेरिफाई करें: रियल-टाइम में टोकन सिग्नेचर वेरिफाई करने के लिए Secret / पब्लिक की का उपयोग करें और तय करें कि 401 'बैड सिग्नेचर', 'एक्सपायर्ड' या 'एल्गोरिदम मिसमैच' है
  • इंटीग्रेशन के दौरान टेस्ट JWT जनरेट करें: टोकन जारी करने के लिए बैकएंड को अस्थायी रूप से कोड बदलने की जरूरत के बिना, ब्राउज़र में टेस्ट की-पेयर के साथ JWT जारी करें
  • PEM ↔ JWK कन्वर्जन: OIDC IdP ने आपको JWK दिया लेकिन सर्वर को PEM चाहिए (या इसके विपरीत) — OpenSSL स्क्रिप्ट लिखने के बजाय जगह पर कन्वर्ट करें
  • 401 Unauthorized को डायगनोज करें: एक्सपायरी, alg-गेटवे मैच, की मैच और PEM फॉर्मेटिंग को स्टेप-बाय-स्टेप चेक करें
  • RS256 बनाम PS256 की तुलना करें: कई OIDC प्रोवाइडर डिफॉल्ट रूप से RS256 का उपयोग करते हैं जबकि AWS SigV4 PS256 को प्राथमिकता देता है — उसी RSA की-पेयर के साथ एल्गोरिदम स्विच करें और नतीजों की तुलना करें
  • JWT के आंतरिक कामकाज को सीखें: alg बदलें, Payload एडिट करें, ब्राउज़र में की बदलें और देखें कि सिग्नेचर रियल-टाइम में कैसे टूटता है — RFC पढ़ने से बहुत तेज

उपयोग कैसे करें

  1. टोकन पेस्ट करें या टाइप करें: JWT स्ट्रिंग को इनपुट फील्ड में रखें; टूल स्वचालित रूप से Header, Payload और Signature को अलग करता है और प्रत्येक को फॉर्मेट किए गए JSON के रूप में प्रदर्शित करता है
  2. एल्गोरिदम चुनें: HS256 / RS256 / ES256 / PS256 / EdDSA के बीच स्विच करें; टूल Header.alg से अनुमान लगाता है और किसी भी मिसमैच को फ्लैग करता है
  3. एक की इम्पोर्ट करें: HMAC Secret, PEM स्ट्रिंग या JWK JSON पेस्ट करें; असममित एल्गोरिदम के लिए, तुरंत टेस्ट की पाने के लिए 'की-पेयर जनरेट' पर क्लिक करें
  4. वेरिफाई करें या फिर से साइन करें: Decode मोड में, पब्लिक की से वेरिफाई करें और '✅ सिग्नेचर वैध / ❌ सिग्नेचर अमान्य' देखें; Encode मोड में, Claims एडिट करें और नया टोकन बनाने के लिए प्राइवेट की से साइन करें

Output Example

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

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

विशेषताएं

  • एक ही जगह पर डिकोड + वेरिफाई + जनरेट: टोकन पेस्ट करके Header/Payload/Signature अलग करें, सिग्नेचर वेरिफाई करने के लिए एल्गोरिदम और की बदलें, नया टोकन बनाने के लिए Claims एडिट करके फिर से साइन करें — पूरे JWT ट्रबलशूटिंग चेन को कवर करता है
  • सभी 13 एल्गोरिदम सपोर्टेड: 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 गेटवे और एंटरप्राइज SSO को कवर करता है
  • PEM और JWK फॉर्मेट: RSA, ECDSA और Ed25519 कीज PEM स्ट्रिंग्स (-----BEGIN PUBLIC KEY----- हेडर्स के साथ) और JWK JSON (kid/kty/n/e फील्ड्स) स्वीकार करती हैं — OIDC /.well-known/jwks.json आउटपुट सीधे पेस्ट करें
  • HMAC Secret की कई इनपुट फॉर्म्स: कच्ची UTF-8 स्ट्रिंग, हेक्स बाइट्स या Base64/Base64URL एन्कोडेड — एक क्लिक में स्विच करें, ताकि 'दिखने में एक जैसा है लेकिन सिग्नेचर फेल हो जाता है' कभी न हो
  • ऑटोमेटिक की-पेयर जनरेशन: RSA-2048, RSA-4096, P-256, P-384 और Ed25519 की-पेयर ब्राउज़र में जनरेट होती हैं, तुरंत टेस्ट यूज़ के लिए PEM और JWK फॉर्मेट में प्रस्तुत की जाती हैं
  • Claims की सेमेंटिक हाइलाइटिंग: exp / iat / nbf स्वचालित रूप से पढ़ने योग्य समय में कन्वर्ट होते हैं, एक्सपायर्ड / अभी-अमान्य / जारी किया गया स्टेटस हाइलाइट के साथ; Header में alg / typ / kid अलग-अलग लेबल किए जाते हैं
  • 100% क्लाइंट-साइड, जीरो अपलोड: हर पार्स, वेरिफाई और साइन ब्राउज़र के नेटिव Web Crypto API के जरिए चलता है — टोकन, कीज और payload कभी ब्राउज़र नहीं छोड़ते, 'प्रोडक्शन टोकन को कभी भी रैंडम ऑनलाइन टूल्स में पेस्ट न करें' सुरक्षा सिद्धांत का पालन करते हुए
  • वन-क्लिक कॉपी: Header, Payload, Signature और नया जनरेट किया गया टोकन स्वतंत्र रूप से कॉपी करने योग्य हैं; डॉक्यूमेंटेशन, टिकट और curl कमांड्स के लिए

कोड उदाहरण

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 साइनिंग एल्गोरिदम की तुलना: कौन सा चुनें?

JWT एक एल्गोरिदम नहीं है — 5 अलग-अलग एल्गोरिदम कुंजी, प्रदर्शन, सुरक्षा और अनुकूलता के मामले में अलग-अलग ट्रेडऑफ़ देते हैं। पहले परिदृश्य तय करें, फिर एल्गोरिदम चुनें — कई गलतियाँ बच जाती हैं।

एल्गोरिदमप्रकारकुंजीप्रदर्शनविशिष्ट परिदृश्यसावधानियाँ
HS256HMAC सममितएक ही Secretअत्यंत तेज़सेवा क्लस्टर के भीतर, भरोसेमंद वातावरण, मोनोलिथिक ऐपSecret सत्यापनकर्ता को लीक न हो; कम से कम 32-बाइट यादृच्छिक
RS256RSA असममितनिजी कुंजी से साइन / सार्वजनिक कुंजी से सत्यापनमध्यमOIDC, API गेटवे, एंटरप्राइज़ SSO, सार्वजनिक-निजी कुंजी अलग करनी होRSASSA-PKCS1-v1_5 का उपयोग; क्रॉस-भाषा padding स्थिर रखें
PS256RSA-PSS असममितनिजी कुंजी से साइन / सार्वजनिक कुंजी से सत्यापनमध्यमAWS SigV4, AWS Cognito, नए OIDC IdPsaltLength स्पष्ट रूप से तय करना ज़रूरी (OpenSSL/jose=32, Go=hash लंबाई)
ES256ECDSA असममितनिजी कुंजी से साइन / सार्वजनिक कुंजी से सत्यापनतेज़ + छोटा साइनApple Sign in with Apple, मोबाइल, कम-बैंडविड्थ परिदृश्यअलग-अलग वक्र (P-256/P-384/P-521) सर्वर से मेल खाने चाहिए
EdDSAEd25519/Ed448निजी कुंजी से साइन / सार्वजनिक कुंजी से सत्यापनअत्यंत तेज़ (निश्चायक साइन)OAuth 2.1, नए प्रोटोकॉल, उच्च-आवृत्ति सत्यापनWeb Crypto Ed25519 का समर्थन करता है; Ed448 सभी प्लेटफ़ॉर्म पर अभी उपलब्ध नहीं

Best Practices

उत्पादन के Secret / निजी कुंजी को कभी भी ऑनलाइन टूल में न चिपकाएँ

यह टूल 100% ब्राउज़र में स्थानीय रूप से काम करता है (कोई भी Token या कुंजी अपलोड नहीं करता), लेकिन एक बार डिबगिंग की आदत बनने पर उत्पादन के दीर्घकालिक Secret / निजी कुंजी / Access Token को अनजाने ऑनलाइन टूल में चिपकाना या स्क्रीनशॉट से लीक करना आसान हो जाता है। दीर्घकालिक Token (Refresh Token, उत्पादन निजी कुंजी, API Key) हमेशा स्थानीय नियंत्रित वातावरण में हैंडल करें; यह टूल केवल अल्पकालिक Access Token की डिबगिंग, टेस्ट की-पेयर, और JWT संरचना सीखने के लिए है।

OWASP JSON Web Token चीट शीट

सर्वर को एल्गोरिदम व्हाइटलिस्ट करना चाहिए; Token Header.alg पर भरोसा न करें

alg: none हमले (CVE-2015-9235 आदि) और HS256 स्वैप हमले (सार्वजनिक कुंजी को Secret बनाकर RSA सर्वर को धोखा देना) दोनों की जड़ यह है कि सर्वर Header में घोषित एल्गोरिदम के आधार पर सत्यापन लॉजिक चुनता है। उत्पादन कोड में `algorithms: ['RS256']` जैसी व्हाइटलिस्ट हार्डकोड होनी चाहिए — Token को यह तय नहीं करने देना चाहिए कि कौन सा एल्गोरिदम उपयोग हो। डिबगिंग में अगर Header.alg सर्वर अपेक्षा से मेल न खाए, तो पहले सर्वर कॉन्फ़िगरेशन पर संदेह करें, Token सामग्री पर नहीं।

HS256 Secret कम से कम 32-बाइट यादृच्छिक मान होना चाहिए

HS256 HMAC-SHA256 पर आधारित है; यदि कुंजी की लंबाई डाइजेस्ट लंबाई (32 बाइट) से कम हो तो ब्रूट-फ़ोर्स लागत काफ़ी कम हो जाती है। `'my-secret'`, `'password123'` जैसे छोटे स्ट्रिंग या व्यवसाय-नाम/कंपनी-नाम/वर्ष का संयोजन उपयोग न करें। मानक तरीका: `openssl rand -base64 32` या `crypto.randomBytes(32).toString('base64url')` से बनाकर एनवायरनमेंट वेरिएबल / KMS / कुंजी प्रबंधन सेवा में रखें, कोड में कभी न लिखें।

क्या JWT संवेदनशील उपयोगकर्ता जानकारी के लिए सुरक्षित जगह है?

उत्पादन JWT में सिर्फ़ साइन नहीं, exp / nbf / iat / iss / aud भी सत्यापित करें

साइन सत्यापन पास होने का मतलब केवल "इसे बदला नहीं गया" है; "अभी मान्य है", "इसे इसी IdP ने जारी किया", "यह इसी ऐप के लिए है" — इनमें से कोई साबित नहीं होता। उत्पादन में exp (समाप्ति), nbf (प्रभावी समय), iat (जारी समय), iss (जारीकर्ता), aud (ऑडियंस) — सभी प्रासंगिक Claim को अनिवार्य रूप से सत्यापित करें, एक भी छूटा नहीं चाहिए। OWASP इन 4-5 आइटमों को अनिवार्य जाँच के रूप में सूचीबद्ध करता है। केवल साइन सत्यापित कर समय की जाँच न करना कई Token लीक घटनाओं (refresh token कभी समाप्त न होना) की जड़ है।

Token समाप्ति की परतें: Access 15-30 मिनट, Refresh 7-30 दिन

Access Token API कॉल के लिए होता है — समाप्ति जितनी छोटी, उतनी सुरक्षित (लीक होने पर जल्दी अमान्य)। Refresh Token Access Token बदलने के लिए होता है, इसकी अवधि लंबी हो सकती है लेकिन यह सर्वर-साइड संग्रहित और रद्द-योग्य होना चाहिए। सामान्य अनुभवजन्य मान: Access 15-30 मिनट, Refresh 7-30 दिन। Refresh Token Rotation (हर बार Refresh से Access बदलते समय नया Refresh भी जारी करना और पुराने Refresh को तुरंत अमान्य करना) के साथ लीक का पता लगाना और उपयोगकर्ता अनुभव दोनों संतुलित होते हैं।

स्टेटलेस बनाम स्टेटफुल प्रमाणीकरण: JWT ≠ Session का विकल्प

JWT अवस्था को Token के अंदर रखता है, इसलिए माइक्रोसर्विस क्षैतिज स्केलिंग और CORS क्रॉस-डोमेन के लिए स्वाभाविक रूप से उपयुक्त है, लेकिन रद्द करने की लागत अधिक है (ब्लैकलिस्ट या छोटी समाप्ति चाहिए)। Session अवस्था को सर्वर-साइड Redis/DB में रखता है और "लॉगआउट पर ज़बरदस्ती बाहर" संभव है, लेकिन साझा स्टोरेज चाहिए। **यह दो में से एक नहीं है**: अल्पकालिक Access JWT + सर्वर-साइड Refresh Token सत्र रिकॉर्ड सबसे आम हाइब्रिड है, जो स्टेटलेस स्केलिंग और तत्काल रद्दीकरण दोनों देता है। तत्काल रद्दीकरण ज़रूरी बैंकिंग/सरकारी कोर सिस्टम में शुद्ध JWT के प्रयोग में सतर्कता बरतें।

क्या JWT संवेदनशील उपयोगकर्ता जानकारी के लिए सुरक्षित जगह है?

Payload डिफ़ॉल्ट रूप से सादा-पाठ है; संवेदनशील डेटा JWT में न डालें

JWT (JWS) डिफ़ॉल्ट रूप से Payload को एन्क्रिप्ट नहीं करता — Token रखने वाला कोई भी व्यक्ति Base64URL डिकोड करके सामग्री पढ़ सकता है। पासवर्ड, राष्ट्रीय ID नंबर, क्रेडिट कार्ड नंबर, API कुंजी, Access Token या Refresh Token को **कभी भी** Payload में न रखें। JWT गैर-संवेदनशील Claims (उपयोगकर्ता ID, भूमिका, समाप्ति, किरायेदार ID) के लिए उपयुक्त है; संवेदनशील डेटा सर्वर-साइड `sub` के माध्यम से क्वेरी किया जाना चाहिए। Payload एन्क्रिप्शन के लिए JWE (RFC 7516) का उपयोग किया जा सकता है, लेकिन प्रदर्शन 2-5 गुना धीमा होता है और कुंजी प्रबंधन जटिल हो जाता है — पहले "गैर-संवेदनशील Claim + सर्वर-साइड क्वेरी" पैटर्न अपनाएँ।

JWT क्या है?

RSA-PSS (PS256/PS384/PS512) क्रॉस-भाषा इंटीग्रेशन में saltLength पहले तय करें

RS256 और PS256 एक-दूसरे से सत्यापित नहीं हो सकते (पैडिंग अलग है)। PS256 में एक और आम गिरावट है: `saltLength` पैरामीटर। OpenSSL डिफ़ॉल्ट 32 बाइट, Node jose डिफ़ॉल्ट 32 बाइट, Python PyJWT डिफ़ॉल्ट hash लंबाई (SHA-256=32), Go डिफ़ॉल्ट `rsa.PSSSaltLengthEqualsHash`। क्रॉस-भाषा इंटीग्रेशन में पहले एक ही मान (अनुशंसित 32 बाइट) तय करें, अन्यथा एक ही RSA की-पेयर से साइन किया गया PS256 Token अलग-अलग भाषाओं में सत्यापन में विफल हो जाएगा।

RS256 और PS256 क्रॉस-भाषा साइन सत्यापन विफलता

डिबगिंग वर्कफ़्लो: टेस्ट की-पेयर का उपयोग करें, उत्पादन को न छुएँ

इंटीग्रेशन या स्थानीय विकास के दौरान हमेशा नई टेस्ट की-पेयर बनाएँ (HS256 के लिए यादृच्छिक Secret, RS256/ES256/EdDSA के लिए टूल-जनित की-पेयर)। उत्पादन IdP की निजी कुंजी या कंपनी-डोमेन के Secret का पुनः उपयोग कभी न करें। डिबगिंग या स्थानीय परीक्षण पूरा होते ही टेस्ट कुंजी को तुरंत नष्ट करें। यह टूल "की-पेयर जनरेट करें" सुविधा इसी उद्देश्य से बनाई गई है — RSA-2048/4096, P-256/P-384, Ed25519 एक क्लिक में तैयार और इंटीग्रेशन समाप्ति पर त्यागने योग्य।

टेस्ट JWT इंटीग्रेशन जनरेशन

सामान्य प्रश्न

JWT के तीन हिस्से क्या हैं?

JWT स्ट्रिंग `Header.Payload.Signature` रूप में होती है, प्रत्येक सेगमेंट Base64URL-एन्कोडेड होता है। Header एल्गोरिदम (जैसे HS256, RS256) और टोकन प्रकार (typ: JWT) को घोषित करता है; Payload उपयोगकर्ता Claims (घोषणाएं) ले जाता है, आम फील्ड्स हैं sub (उपयोगकर्ता ID), iat (जारी करने का समय), exp (समाप्ति समय), nbf (not-before), aud (दर्शक), iss (जारीकर्ता); Signature पहले दो सेगमेंट्स को की के साथ साइन करने का परिणाम है, उद्देश्य 'टैम्परिंग डिटेक्शन' है 'लीक-प्रिवेंशन' नहीं।

क्या मैं डिकोड करने के बाद Payload एडिट कर सकता हूं?

आप देख और एडिट कर सकते हैं, लेकिन **फर्जी नहीं बना सकते**। जैसे ही आप Header या Payload बदलते हैं, मूल Signature अमान्य हो जाता है और सर्वर वेरिफिकेशन को अस्वीकार कर देता है। संशोधित टोकन को फिर से वैध बनाने के लिए, आपको उसी एल्गोरिदम और उसी की के साथ **फिर से साइन** करना होगा — यही कारण है कि यह टूल एक ही जगह पर 'डिकोड + एडिट + जनरेट' प्रदान करता है: देखने के लिए डिकोड करें, बदलें और तुरंत टेस्ट के लिए नया टोकन जनरेट करें, ताकि आपको हर बार बैकएंड से टोकन जारी करने के लिए कोड अस्थायी रूप से बदलने का अनुरोध न करना पड़े।

HS256, RS256, ES256, PS256 और EdDSA में क्या अंतर है?

HS256 साझा Secret के साथ HMAC का उपयोग करता है (सममित), तेज लेकिन secret प्रबंधन महत्वपूर्ण है। RS256 RSA प्राइवेट/पब्लिक कीज का उपयोग करता है (असममित), जारीकर्ता प्राइवेट के साथ साइन करता है, वेरिफायर पब्लिक का उपयोग करता है। ES256 एलिप्टिक कर्व ECDSA का उपयोग करता है (P-256), छोटा सिग्नेचर। PS256 RSA-PSS का उपयोग करता है, RS256 से अधिक सुरक्षित। EdDSA (आमतौर पर Ed25519) तेज और नियतिवादी है, OAuth 2.1 के लिए अनुशंसित।

मेरा JWT क्यों लगातार 'Invalid Signature' दिखा रहा है?

आमतौर पर इसलिए क्योंकि की, Secret फॉर्मेट, एल्गोरिदम या Base64URL एन्कोडिंग बिल्कुल मेल नहीं खाते। एक अतिरिक्त स्पेस, गलत PEM नई लाइन या Base64 और Base64URL के बीच भ्रम पर्याप्त है। बाइट-दर-बाइट मेल की जांच करें और पुष्टि करें कि Header.alg चुने गए एल्गोरिदम से मेल खाता है।

क्या एक ही RSA की RS256 और PS256 को क्रॉस-वेरिफाई कर सकती है?

नहीं। RS256 RSASSA-PKCS1-v1_5 का उपयोग करता है, PS256 RSA-PSS का उपयोग करता है। एक ही RSA की के साथ भी, वे क्रॉस-वेरिफाई नहीं कर सकते। साइनर और वेरिफायर को एक ही एल्गोरिदम का उपयोग करना चाहिए।

alg:none अटैक क्या है?

एक हमलावर Header को `{"alg":"none"}` (कोई सिग्नेचर नहीं) में बदलता है या RS256 को HS256 से बदलता है (पब्लिक की का उपयोग HMAC Secret के रूप में करता है)। सर्वर को एल्गोरिदम व्हाइटलिस्ट लागू करनी चाहिए और कभी टोकन को यह तय करने न दें कि कौन सा एल्गोरिदम उपयोग करना है।

मैं PEM और JWK के बीच कैसे कन्वर्ट करूं?

PEM BEGIN/END लाइनों के साथ क्लासिक OpenSSL नोटेशन है। JWK JSON है और OAuth/OIDC में आम है। OIDC प्रोवाइडर अक्सर `/.well-known/jwks.json` के माध्यम से पब्लिक कीज प्रकाशित करते हैं। यह टूल सीधे PEM और JWK फॉर्मेट्स को संसाधित कर सकता है।

क्या ब्राउज़र सीधे JWT सिग्नेचर वेरिफाई कर सकता है?

हां। ब्राउज़र का नेटिव Web Crypto API (`window.crypto.subtle`) तीसरे पक्ष की लाइब्रेरी के बिना HMAC, RSA, ECDSA, RSA-PSS और Ed25519 साइनिंग और वेरिफिकेशन का समर्थन करता है। यह टूल प्रत्येक वेरिफिकेशन के लिए फ्रंट-एंड पर `crypto.subtle.importKey` और `crypto.subtle.verify` का उपयोग करता है, इसलिए कभी आपके टोकन या कीज नहीं भेजता। नोट: Web Crypto केवल सुरक्षित संदर्भों में उपलब्ध है: **HTTPS** या `localhost`।

क्या मेरा टोकन सर्वर पर भेजा जाता है?

नहीं। इस टूल में सभी पार्सिंग, वेरिफिकेशन और साइनिंग नेटिव Web Crypto API के माध्यम से ब्राउज़र में चलता है। टोकन, Header, Payload, Signature, secret / प्राइवेट की और कोई भी जनरेट की गई की-पेयर कभी सर्वर पर नहीं भेजे जाते। अपने ब्राउज़र के DevTools Network टैब खोलें और आप टोकन सामग्री ले जाने वाला कोई आउटगोइंग अनुरोध नहीं देखेंगे। पेज लोड होने के बाद ऑफलाइन उपयोग किया जा सकता है।

क्या JWT संवेदनशील उपयोगकर्ता जानकारी के लिए सुरक्षित जगह है?

**नहीं।** JWT Payload डिफॉल्ट रूप से प्लेन-टेक्स्ट होता है — टोकन वाला कोई भी व्यक्ति इसे Base64URL में डिकोड करके सामग्री पढ़ सकता है। कोई एन्क्रिप्शन नहीं है। **कभी भी** पासवर्ड, राष्ट्रीय ID नंबर, क्रेडिट कार्ड नंबर, API कीज, एक्सेस टोकन या रिफ्रेश टोकन को JWT में प्लेन-टेक्स्ट के रूप में न रखें। यदि आपको एन्क्रिप्शन की आवश्यकता है, JWS के बजाय JWE (RFC 7516) का उपयोग करें। JWT गैर-संवेदनशील Claims (उपयोगकर्ता ID, भूमिका, समाप्ति, किरायेदार ID) के लिए उपयुक्त हैं; संवेदनशील डेटा को सर्वर-साइड पर `sub` का उपयोग करके क्वेरी किया जाना चाहिए।

समस्या निवारण

Invalid Signature: 'signature is invalid'

टोकन और वेरिफिकेशन की मेल नहीं खाते। आम कारण: (1) सर्वर की और टूल में पेस्ट की गई की अलग हैं (सबसे आम); (2) की में अदृश्य अक्षर हैं (अंत में स्पेस, नई लाइन, शून्य-चौड़ाई अक्षर); (3) Base64 और Base64URL मिश्रित हैं; (4) गलत एल्गोरिदम चुना गया है (Header HS256 कहता है, सर्वर RS256 के रूप में वेरिफाई करता है या इसके विपरीत)। पहले जांचें कि की बाइट-दर-बाइट मेल खाती है: PEM की अंत की नई लाइनों, HMAC Secret के अंत के स्पेस और JWK `k` मानों पर ध्यान दें जो URL द्वारा गलत तरीके से डिकोड किए गए हो सकते हैं। पुष्टि करें कि टूल में एल्गोरिदम टोकन के Header.alg से मेल खाता है। सटीक त्रुटि को पुन: पेश करने और 'डिकोड सफल' और 'वेरिफिकेशन विफल' के बीच होने की पुष्टि करने के लिए इस टूल के decode-plus-verify का उपयोग करें।

HTTP 401 Unauthorized: Token Expired या iat भविष्य में

सिग्नेचर वेरिफिकेशन पास हो गया लेकिन `exp` अतीत में है (Token Expired), `nbf` अभी भी भविष्य में है (Not Before) या `iat` सर्वर के वर्तमान समय के बाद है (अक्सर घड़ी सिंक ड्रिफ्ट के कारण)। एक और आम मामला मेल न खाने वाला `aud` (दर्शक) है: टोकन ऐप A के लिए जारी किया गया था लेकिन ऐप B द्वारा वेरिफाई किया जा रहा है। exp / nbf / iat स्टेटस तुरंत देखने के लिए इस टूल में हाइलाइट किए गए Claims क्षेत्र का उपयोग करें। लाल exp = समाप्त, फिर से जारी करें। लाल nbf = अभी अमान्य, जांचें कि iat भविष्य का समय है या नहीं। लाल aud = गलत दर्शक, जांचें कि सर्वर सही दर्शक के साथ कॉन्फ़िगर है या नहीं।

PEM या JWK इम्पोर्ट त्रुटि

PEM में अतिरिक्त खाली लाइनें हैं या हेडर/फुटर मार्कर गायब हैं (`-----BEGIN PUBLIC KEY-----`); JWK में आवश्यक फील्ड गायब हैं (`kty` / `n` / `e` / `kid`); JWK `k` मान Base64URL पैडिंग से रहित है (`=` से पैड किया जाना चाहिए या सख्ती से `=` के बिना); RSA प्राइवेट की को पब्लिक की के रूप में इम्पोर्ट किया जा रहा है; Ed25519 प्राइवेट की (32-बाइट सीड) 64 बाइट्स के रूप में प्रदान की जा रही है। `openssl rsa -in key.pem -pubout -outform PEM` या `openssl ec -in key.pem -pubout` के साथ मानक PKIX PEM को फिर से निर्यात करें; JWK के लिए, मैन्युअल रूप से एन्कोड करने के बजाय OIDC Discovery एंडपॉइंट `/.well-known/jwks.json` से कच्चा आउटपुट उपयोग करें। यह टूल स्वचालित रूप से PEM हेडर्स, गायब पैडिंग और गायब JWK फील्ड्स का पता लगाता है और संकेत देता है।

RS256 बनाम PS256 भाषाओं के बीच सिग्नेचर विफलताएं

RS256 RSASSA-PKCS1-v1_5 का उपयोग करता है, PS256 RSA-PSS का उपयोग करता है। ये दोनों **क्रॉस-वेरिफाई नहीं कर सकते** — एक निश्चित RSA की के साथ RS256 में साइन किया गया टोकन हमेशा PS256 वेरिफिकेशन में विफल होगा, और सिग्नेचर लंबाई में कुछ बाइट्स से भिन्न हो सकता है। सुनिश्चित करें कि साइनर और वेरिफायर एक ही एल्गोरिदम का उपयोग करते हैं। AWS SigV4 PS256 का उपयोग करता है, अधिकांश OIDC IdP RS256 का उपयोग करते हैं। RSA-PSS में `saltLength` पैरामीटर भी होता है — OpenSSL डिफॉल्ट 32, jose डिफॉल्ट 32, Go का `rsa.PSSOptions{SaltLength: rsa.PSSSaltLengthEqualsHash}` सही समकक्ष है। भाषाओं के बीच इंटीग्रेशन टेस्टिंग से पहले इसे लॉक करें।

alg:none अटैक और HS256 की रिप्लेसमेंट अटैक

सर्वर टोकन के Header में घोषित alg के आधार पर वेरिफिकेशन एल्गोरिदम चुनता है। एक हमलावर हेडर को `alg: none` (कोई सिग्नेचर नहीं) में फिर से लिखता है या RS256 टोकन को HS256 में फिर से लिखता है (पब्लिक की का उपयोग साझा HMAC Secret के रूप में करता है) और वेरिफिकेशन को बायपास करता है। CVE-2015-9235 (jsonwebtoken) और CVE-2022-23529 (कई Node लाइब्रेरी) जैसे ऐतिहासिक CVE इसी पैटर्न से उत्पन्न होते हैं। सर्वर को एल्गोरिदम व्हाइटलिस्ट लागू करनी चाहिए — उदाहरण `algorithms: ['RS256']` — और कभी टोकन को यह तय करने न दें कि कौन सा एल्गोरिदम उपयोग करना है। इस टूल का UI दोनों Header.alg और आपके द्वारा वास्तव में चुने गए एल्गोरिदम को दिखाता है, और मिसमैच को फ्लैग करता है: यह 'क्लाइंट को Header.alg पर भरोसा नहीं करना चाहिए' का लाइव डेमो है।

Privacy & Security

यह JWT वर्कबेंच आपके ब्राउज़र में 100% चलता है, ब्राउज़र के नेटिव Web Crypto API द्वारा समर्थित। आप जो टोकन पेस्ट करते हैं, Header, Payload, Signature, HMAC Secret, कोई भी RSA/ECDSA प्राइवेट की, कोई भी जनरेट की गई की-पेयर और हर सिग्नेचर/वेरिफिकेशन गणना आपके डिवाइस पर रहती है — वे कभी सर्वर पर नहीं जाते, कभी लॉग नहीं होते, कभी विश्लेषित नहीं होते और कभी कैश नहीं होते। पेज लोड होने के बाद ऑफलाइन उपयोग किया जा सकता है। सर्वोत्तम अभ्यास: कभी भी लंबे समय तक चलने वाले प्रोडक्शन टोकन या प्रोडक्शन प्राइवेट कीज को इस सहित किसी भी ऑनलाइन टूल में पेस्ट न करें। यह टूल डिबगिंग, इंटीग्रेशन टेस्टिंग, सीखने और टेस्ट टोकन जनरेशन के लिए उपयुक्त है — प्रोडक्शन secrets और प्राइवेट कीज को नियंत्रित, स्थानीय वातावरण में संसाधित किया जाना चाहिए।

Supported Video Formats

FormatMIMEBrowser supportWhen to use
HS256 / HS384 / HS512HMAC + SHA-256/384/512UniversalSymmetric key algorithm: वही Secret साइन और वेरिफाई दोनों करता है। यह सरल और तेज है, इसलिए trusted boundary के भीतर चलने वाले service cluster के लिए अच्छा है। Secret कम से कम HS256 के लिए 32 bytes, HS384 के लिए 48 bytes और HS512 के लिए 64 bytes होना चाहिए।
RS256 / RS384 / RS512RSASSA-PKCS1-v1_5 + SHA-2Web Crypto APIसबसे आम asymmetric algorithm। private key से sign किया जाता है और public key से verify किया जाता है। अधिकतर OIDC providers, API gateways और enterprise SSO में यही default विकल्प होता है।
PS256 / PS384 / PS512RSA-PSS + SHA-2Web Crypto APIRSA-PSS, RS256 का नया और अधिक सुरक्षित विकल्प है। AWS SigV4, AWS Cognito और modern OIDC providers अक्सर इसे प्राथमिकता देते हैं। verification match कराने के लिए saltLength साफ़ तौर पर सेट करना ज़रूरी है।
ES256 / ES384 / ES512ECDSA + P-256/P-384/P-521Web Crypto APIElliptic-curve signatures। Signature छोटा होता है (ES256 सिर्फ 64 bytes), performance अच्छी रहती है और JWT छोटा बनता है। Sign in with Apple default रूप से ES256 इस्तेमाल करता है।
EdDSA (Ed25519)Ed25519 / Ed448Web Crypto APIनई पीढ़ी का high-performance signature algorithm। Signatures deterministic होते हैं (same message + same key = same signature), nonce reuse का जोखिम नहीं रहता और नए protocols के लिए यह अच्छा विकल्प है।

Authoritative References