§

JWT paste ചെയ്യുക

Parsing, signature verification ഇരുവരും locally run ആകുന്നു. Token-നെ കുറിച്ചുള്ള ഒന്നും server-ലേക്ക് അയക്കുന്നില്ല.
§

ഹെഡർ

json
§

പേലോഡ്

json
§

Signature verify ചെയ്യൽ

Signature verify ചെയ്യാൻ secret നൽകുക.

JSON Web Tokens Kerala-ന്റെ authentication stack drive ചെയ്യുന്നു — AWS Cognito ID tokens, Auth0, Okta access tokens, Stripe-signed event tokens ഒക്കെ JWT ഉപയോഗിക്കുന്നു. Open Banking framework-ൽ ജോലി ചെയ്യുന്ന fintech teams-ഉം ഇതേ RFC 7519 envelope ആശ്രയിക്കുന്നു. ഈ decoder browser-ൽ മൂന്ന് Base64URL segments split ചെയ്‌ത്, header, payload, signature surface ചെയ്‌ത്, `exp`, `iat`, `nbf` standard claims proper time-zone rendering ഉൾക്കൊണ്ട് decode ചെയ്യുന്നു — bearer token tab വിടുന്നില്ല, server-side log-ൽ appear ആകില്ല.

JSON Web Token എന്നത് എന്താണ്?

ഒരു JSON Web Token (JWT) ഒരു small claims payload-ന് compact, URL-safe envelope ആണ്. Stateless web sessions, OAuth/OIDC ID tokens, machine-to-machine API auth, signed magic links-ന്റെ standard credential format ആണ്. JWT എല്ലായ്‌പ്പോഴും dots ഉൾക്കൊണ്ട് joined മൂന്ന് base64url segments ആണ്: header.payload.signature. Header, payload JSON ആണ്; signature ആദ്യ രണ്ട് segments-ന്റെ binary MAC അല്ലെങ്കിൽ digital signature ആണ്.

JWTs എങ്ങനെ പ്രവർത്തിക്കുന്നു?

ഈ ടൂൾ token decode ചെയ്യുമ്പോൾ ഓരോ JWT library-ഉം follow ചെയ്യുന്ന അതേ three-step path walk ചെയ്യുന്നു:

  1. Token dots-ൽ split ചെയ്‌ത് exactly മൂന്ന് non-empty segments ആക്കൽ. മറ്റേത് shape-ഉം malformed.
  2. Segments 0, 1 Base64url-decode ചെയ്‌ത് ഓരോന്നും JSON.parse ചെയ്യൽ. Header algorithm (alg), token type (typ) carry ചെയ്യുന്നു. Payload claims (sub, exp, iat, custom keys) carry ചെയ്യുന്നു.
  3. Secret provide ചെയ്‌തിട്ടുണ്ടെങ്കിൽ header-ന്റെ algorithm ഉപയോഗിച്ച് <segment0>.<segment1>-ൽ MAC recompute ചെയ്‌ത് third segment-ൽ നിന്ന് bytes compare ചെയ്യൽ.
  4. exp claim-ൽ നിന്ന് human-readable expiry indicator compute ചെയ്‌ത് decoded claims ഒൾക്കൊണ്ട് verification result surface ചെയ്യൽ.

ബ്രൗസറിൽ JWTs decode ചെയ്യേണ്ടത് എന്തുകൊണ്ട്?

Real, in-use JWT remote debugger-ൽ paste ചെയ്‌ത് credential ആ service-ന്റെ logs-ലേക്ക് leak ചെയ്യുന്നു. Third-party site token log ചെയ്യില്ലെന്ന് claim ചെയ്‌താലും verify ചെയ്യാൻ കഴിയില്ല. ഈ ടൂൾ ആ compromise ഒഴിവാക്കാൻ build ചെയ്‌തതാണ്:

  • Zero network: runtime-ൽ fetch, XMLHttpRequest, sendBeacon calls ഇല്ല. Decode, verify ചെയ്യുന്നതിനിടെ DevTools തുറക്കുക — Network panel silent.
  • Native Web Crypto: HMAC verification crypto.subtle.importKey, crypto.subtle.sign ഉപയോഗിക്കുന്നു — runtime call ചെയ്യുന്ന primitives.
  • Static deploy: ഓരോ page-ഉം single static HTML file, server endpoint ഇല്ല. Token leak ആകില്ല, leak ആക്കാൻ server ഇല്ല.

ഈ ടൂൾ verify ചെയ്യുന്നത്, verify ചെയ്യാത്തത് എന്ത്?

ഈ ടൂളിന്റെ version 1 HMAC-SHA family signatures മാത്രം verify ചെയ്യുന്നു:

  • Supported: HS256, HS384, HS512. Shared secret provide ചെയ്‌ത് MAC recompute, compare ചെയ്യാൻ ടൂൾ.
  • ഇതുവരെ supported ഇല്ല: RS256/384/512 (RSA), ES256/384/512 (ECDSA), EdDSA, PS256/384/512 (RSA-PSS). ഇവ PEM/JWK form-ൽ public key ആവശ്യമാണ്, follow-up release-ലേക്ക് deferred.
  • Refused: alg: "none". ടൂൾ token decode ചെയ്യുന്നു, insecure ആക്കി flag ചെയ്യുന്നു — signature validation ഇല്ല, ഇത് accept ചെയ്യുന്ന ഏത് production system-ഉം serious vulnerability ഉള്ളതാണ്.

JWT decoding ഉദാഹരണം?

Canonical RFC 7519 example token മുകളിലെ input field-ൽ paste ചെയ്യുക:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header {"alg":"HS256","typ":"JWT"}-ലേക്ക് decode ആകുന്നു, payload {"sub":"1234567890","name":"John Doe","iat":1516239022}-ലേക്ക്. Verify panel-ൽ your-256-bit-secret enter ചെയ്‌ത് signature check valid return ചെയ്യുന്നു. Secret-ൽ ഒരൊറ്റ character മാറ്റിയാൽ invalid return ചെയ്യുന്നു. ഇതൊന്നും ബ്രൗസർ വിടുന്നില്ല.

Production-ൽ token debug ചെയ്യേണ്ടി വന്നപ്പോൾ ആഗ്രഹിച്ച JWT decoder ഇതാണ്: privacy-respecting, fast, runtime ഉപയോഗിക്കുന്ന primitives ഉൾക്കൊണ്ട്.