JWT (JSON Web Token) és un estàndard obert definit per l'IETF al RFC 7519 (el RFC 7515 descriu la forma de signatura JWS, el RFC 7516 descriu el xifratge JWE, el RFC 7517 defineix les claus JWK) per transferir de manera segura 'informació declarada' de l'usuari entre peticions HTTP, fluxos OIDC i crides de microserveis. Una cadena JWT estàndard està composta per tres segments codificats en Base64URL: Header (algoritme i tipus), Payload (Claims, les dades de l'usuari) i Signature (una signatura basada en clau sobre els dos primers). Els tres segments s'uneixen amb un punt literal `.`, p. ex. `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.
**JWT no és xifratge.** Aquest és el malentès més comú. El Payload és text pla per defecte — qualsevol pot descodificar-lo amb Base64URL i llegir el contingut. JWT proporciona **detecció de manipulació**, no confidencialitat: el servidor torna a signar Header.Payload amb la clau compartida i la compara amb la Signature del token. Si coincideixen, el token no s'ha alterat en trànsit. Aquesta és la metàfora del 'bitllet de tren amb un segell anti-falsificació': a l'inspector li importa si el bitllet és genuí, no si el codi QR és illegible.
JWT divideix clarament les responsabilitats entre 13 algoritmes. **Família HMAC** (HS256/HS384/HS512) utilitza una clau simètrica tant per signar com per verificar, ràpida i senzilla, adequada per a un sol servei o un clúster de confiança; el secret ha de ser com a mínim la longitud del resum (p. ex. ≥ 32 bytes per a HS256). **Família RSA** (RS256/RS384/RS512) utilitza RSASSA-PKCS1-v1_5, l'esquema asimètric més comú — els signataris tenen la clau privada, els verificadors tenen la clau pública. **Família RSA-PSS** (PS256/PS384/PS512) utilitza el farciment RSA-PSS més nou amb garanties de seguretat més fortes, preferit per AWS SigV4 i proveïdors d'identitat OIDC moderns. **Família ECDSA** (ES256/ES384/ES512) utilitza corbes el·líptiques (P-256/P-384/P-521 respectivament) amb signatures més curtes i millor rendiment. **EdDSA** (principalment Ed25519) és extremadament ràpid i determinista (mateix missatge + mateixa clau = mateixa signatura cada vegada) i és l'algoritme recomanat a OAuth 2.1 i nous protocols.
La seguretat és on JWT ensopega en producció. El JWT Cheat Sheet d'OWASP destaca almenys quatre regles estrictes: (1) mai posis contrasenyes, DNI, números de targeta o claus API com a text pla al Payload; (2) el servidor mai ha de **confiar en el camp alg** declarat al Header del Token — ha de verificar amb un algoritme codificat, altrament un atacant que reescrigui la capçalera a `alg: none` ho eludeix tot (aquesta és l'arrel de CVEs històrics com CVE-2015-9235); (3) els secrets HMAC han de ser aleatoris i de com a mínim 32 bytes, mai cadenes curtes; (4) la verificació és més que comprovacions de signatura — també has de validar `exp` (expiració), `nbf` (no abans de), `iss` (emissor) i `aud` (audiència). Aquesta eina ressalta cadascun d'aquests Claims a la UI perquè puguis dir d'un cop d'ull si una fallada és un problema de signatura, un problema de temps o un problema de Claims.
JWT no és un reemplaçament de les sessions. Les sessions emmagatzemen l'estat de l'usuari al servidor (Redis o una base de dades); JWT empaqueta l'estat al token. Les arquitectures de microserveis, APIs sense estat, clients mòbils i configuracions amb molt CORS es beneficien de JWT; els sistemes empresarials tradicionals i els fluxos que requereixen revocació instantània (p. ex. 'fer fora aquest usuari ara') encara són millor atesos per sessions. Aquesta eina cobreix tant la depuració pura de JWT com els passos d'anàlisi de Token / verificació de signatura / edició de Payload d'una migració de sessió a JWT.