logo
GeekFormat

Decodificador, Verificador i Generador JWT

Encoded Token172 charsActualitzat el 2026-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· Subjecte1234567890
name· NameJohn Doe
admin· Admintrue
iat· Emès a151623902218/01/2018 09:30:22
Header details2 items
algHS256HMAC (simètric)
typ· TypeJWT
All operations run locally in your browser; the Token and key are never sent to any server.

Banc de treball JWT gratuït en línia: decodifica, verifica i genera JSON Web Tokens. Admet 13 algoritmes (HS256 / RS256 / ES256 / PS256 / EdDSA, etc.). Claus PEM i JWK. Generació automàtica de parells de claus. exp/iat/nbf analitzats automàticament. 100% client-side — el token mai surt del navegador.

Relacionats

Casos d'ús

  • Decodifica JWT en línia: separa ràpidament un token durant la depuració d'inici de sessió OAuth 2.0 / OIDC per inspeccionar l'algoritme del Header i els Claims del Payload
  • Verifica signatures JWT: utilitza un Secret / clau pública per validar signatures de tokens en temps real i decidir si un 401 és 'signatura incorrecta', 'expirat' o 'incompatibilitat d'algoritme'
  • Genera JWTs de prova durant la integració: emet un JWT al navegador amb un parell de claus de prova, sense necessitat de demanar al backend que canviï temporalment el codi per generar un token
  • Conversió PEM ↔ JWK: l'IdP OIDC et va donar JWK però el servidor necessita PEM (o viceversa) — converteix al lloc en lloc d'escriure un script OpenSSL
  • Diagnostica 401 Unauthorized: revisa pas a pas l'expiració, la coincidència d'algoritme amb la passarel·la, la coincidència de claus i el format PEM
  • Compara RS256 vs PS256: molts proveïdors OIDC utilitzen RS256 per defecte mentre que AWS SigV4 prefereix PS256 — canvia d'algoritme amb el mateix parell de claus RSA i compara resultats
  • Aprèn els internals de JWT: canvia l'algoritme, edita el Payload, intercanvia la clau al navegador i observa com es trenca la signatura en temps real — molt més ràpid que llegir el RFC

Característiques

  • Decodifica + Verifica + Genera en un sol lloc: enganxa un token per separar Header/Payload/Signature, canvia l'algoritme i la clau per verificar la signatura, edita Claims i torna a signar per produir un nou token — cobreix tota la cadena de resolució de problemes JWT
  • Tots els 13 algoritmes suportats: HS256/HS384/HS512 (HMAC), RS256/RS384/RS512 (RSA-PKCS1-v1_5), ES256/ES384/ES512 (ECDSA), PS256/PS384/PS512 (RSA-PSS), EdDSA — cobreix OAuth 2.0, OIDC, JWS, passarel·les API i SSO empresarial
  • Formats PEM i JWK: les claus RSA, ECDSA i Ed25519 accepten cadenes PEM (amb capçaleres -----BEGIN PUBLIC KEY-----) i JSON JWK (camps kid/kty/n/e) — deixa anar directament una sortida OIDC /.well-known/jwks.json
  • Múltiples formes d'entrada de secret HMAC: cadena UTF-8 crua, bytes hexadecimals o secret codificat en Base64/Base64URL — canvia amb un clic, perquè 'sembla igual però la signatura falla' mai passi
  • Generació automàtica de parells de claus: parells de claus RSA-2048, RSA-4096, P-256, P-384 i Ed25519 generats al navegador, presentats en formats PEM i JWK per a ús immediat en proves
  • Ressaltat semàntic de Claims: exp / iat / nbf convertits automàticament a temps llegible per humans amb estat expirat / encara no vàlid / emès ressaltat; alg / typ / kid al Header etiquetats individualment
  • 100% client-side, zero càrrega: cada anàlisi, verificació i signatura s'executa a través de la Web Crypto API nativa del navegador — els tokens, claus i payload mai surten del navegador, coincident amb el principi de seguretat de 'mai enganxar tokens de producció en eines en línia aleatòries'
  • Còpia amb un clic: Header, Payload, Signature i el token generat recentment són cadascun copiables independentment per a documentació, tiquets i comandes curl

Com usar-ho

  1. Enganxa o escriu el token: deixa la cadena JWT al quadre d'entrada; l'eina separa automàticament Header, Payload i Signature i mostra cadascun amb format JSON
  2. Selecciona l'algoritme: canvia entre HS256 / RS256 / ES256 / PS256 / EdDSA; l'eina infereix del Header.alg i marca qualsevol incompatibilitat
  3. Importa una clau: enganxa un secret HMAC, una cadena PEM o un JSON JWK; per a algoritmes asimètrics, fes clic a 'Generar parell de claus' per obtenir una clau de prova immediatament
  4. Verifica o torna a signar: en mode Decode verifica amb una clau pública i veu '✅ signatura vàlida / ❌ signatura invàlida'; en mode Encode edita Claims i signa amb una clau privada per produir un nou token

Preguntes freqients

Quines són les tres parts d'un JWT?

La cadena JWT està composta per tres segments `Header.Payload.Signature`, cadascun codificat en Base64URL. El Header declara l'algoritme (com HS256, RS256) i el tipus de token (typ: JWT); el Payload porta les declaracions de l'usuari (Claims), els camps comuns són sub (ID d'usuari), iat (hora d'emissió), exp (hora d'expiració), nbf (no abans de), aud (audiència), iss (emissor); la Signature és el resultat de signar els dos primers segments amb una clau, el seu propòsit és 'detecció de manipulació' no 'prevenció de vigilància'.

Puc editar el Payload després de descodificar un JWT?

Pots veure'l i editar-lo, però **no pots falsificar-lo**. Un cop canvies el Header o el Payload, la Signature original esdevé invàlida immediatament i el servidor la rebutjarà. Per fer que el token modificat sigui utilitzable de nou, has de **tornar a signar-lo** amb el mateix algoritme i clau — aquesta és precisament la raó per la qual aquesta eina proporciona 'decodificació + edició + generació' en un sol lloc: descodifica per fer un cop d'ull, canvia el que necessitis i genera directament un nou token per a proves, evitant haver de demanar al backend que canviï temporalment el codi per emetre'n un.

Quina és la diferència entre HS256, RS256, ES256, PS256 i EdDSA?

HS256 utilitza HMAC amb un Secret compartit (simètric), ràpid però requereix gestionar el Secret de manera segura; RS256 utilitza claus RSA privada/pública (asimètric), adequat per a escenaris on el signant i el verificador estan separats; PS256 utilitza farciment RSA-PSS, més segur que RS256; ES256 utilitza corbes el·líptiques P-256, signatura més curta i millor rendiment; EdDSA (normalment Ed25519) és extremadament ràpid i determinista, recomanat per a nous protocols com OAuth 2.1.

Per què el meu JWT mostra Signatura Invàlida?

La raó més comuna és que la clau, el format del Secret, l'algoritme o la codificació Base64URL no coincideixen exactament. Un espai extra, un salt de línia PEM, confondre Base64 amb Base64URL, o que el servidor utilitzi RS256 mentre l'eina utilitza HS256 farà fallar la verificació. Utilitza aquesta eina per canviar l'algoritme i el format del Secret per provar un per un.

La mateixa clau RSA serveix per verificar RS256 i PS256?

No. RS256 i PS256 utilitzen esquemes de farciment diferents (PKCS1-v1_5 vs PSS). Encara que la clau RSA sigui la mateixa, no es poden verificar creuadament. El signant i el verificador han d'utilitzar el mateix algoritme.

Què és un atac alg:none?

Un atacant canvia el Header a `{"alg":"none"}`, indicant al servidor que no verifiqui la signatura, o canvia RS256 a HS256 i utilitza la clau pública com a Secret HMAC per enganyar el servidor. El servidor ha d'utilitzar una llista blanca d'algoritmes (com `algorithms: ['RS256']`) i mai confiar en el Header.alg del token per decidir l'algoritme de verificació.

Com converteixo entre PEM i JWK?

PEM és el format clàssic d'OpenSSL amb línies BEGIN/END, comú en configuracions tradicionals; JWK és format JSON, comú en OAuth 2.0 / OIDC. Molts IdP publiquen claus públiques a `/.well-known/jwks.json`. Aquesta eina accepta tots dos formats i pot canviar entre ells.

El navegador pot verificar signatures JWT directament?

Sí. La Web Crypto API admet HMAC, RSA, ECDSA, RSA-PSS i Ed25519 en navegadors moderns. Per això aquesta eina pot verificar signatures directament al navegador sense pujar el token.

El meu token s'envia a un servidor?

No. L'anàlisi, verificació i signatura es fan al navegador. El panell Network no hauria de mostrar cap petició que contingui el token.

Puc guardar dades sensibles en un JWT?

No. El Payload es pot llegir per defecto (només cal descodificar amb Base64URL). Contrasenyes, DNI, números de targeta, claus API, Access Tokens o Refresh Tokens no s'han de posar mai en un JWT estàndard. Si necessites confidencialitat, considera JWE (JSON Web Encryption).

Què és el Decodificador, Verificador i Generador JWT?

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.

Code Examples

50 línies de Node.js: signatura i verificació HS256 escrita a mà

javascript

Destil·la el mecanisme central de JWT: codifica Header i Payload en Base64URL, després fes HMAC-SHA256 de la cadena `header.payload`. En producció, utilitza una biblioteca com jsonwebtoken o jose — aquest fragment existeix per fer depurables les fallades de signatura.

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

Costat del navegador: Web Crypto API per a signatura HMAC

html

La idea central del front-end d'aquesta eina: utilitza crypto.subtle natiu del navegador per a HMAC, RSA, ECDSA, RSA-PSS i verificació Ed25519 — no cal biblioteca de tercers. Deixa això en qualsevol pàgina HTML per generar tokens HS256.

<!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: verifica RS256 amb jose (la manera correcta)

javascript

Utilitza una biblioteca madura com jose, jsonwebtoken o PyJWT en producció — mai ho facis tu mateix. Aquest fragment mostra com jose verifica un token RS256, imprimeix el motiu de fallada en cas d'error (incompatibilitat d'algoritme, signatura incorrecta, expirat, kid no trobat, 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'],     // crític: la llista blanca d'algoritmes bloqueja atacs alg:none i substitució HS256
    }
  )
  console.log('alg =', protectedHeader.alg)
  console.log('sub  =', payload.sub)
} catch (err) {
  console.error('verify failed:', err.code, err.message)
  // comú: ERR_JWT_EXPIRED / ERR_JWS_INVALID / ERR_JWS_SIGNATURE_VERIFICATION_FAILED
}

Python: analitza un token i imprimeix els seus Claims amb PyJWT

python

La manera més comuna de depurar JWT al costat de Python. decode() de PyJWT valida exp / nbf / iat per defecte i retorna el resultat com un dict pla.

import jwt

token = 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxw'

# Analitza (sense comprovació de signatura, només mira Header i Payload)
print(jwt.get_unverified_header(token))
# {'alg': 'HS256', 'typ': 'JWT'}

print(jwt.decode(token, options={'verify_signature': False}))
# {'sub': '1234'}

# Verificació completa
claims = jwt.decode(
    token,
    'my-super-secret-key',
    algorithms=['HS256'],
    audience='my-app',
    issuer='my-service',
)
print(claims['sub'])

Supported Video Formats

FormatMIMEBrowser supportWhen to use
HS256 / HS384 / HS512HMAC + SHA-256/384/512UniversalAlgoritme de clau simètrica. El mateix Secret signa i verifica, senzill i ràpid, adequat per a clústers de serveis dins d'un límit de confiança. El Secret ha de ser de com a mínim 32 bytes aleatoris.
RS256 / RS384 / RS512RSASSA-PKCS1-v1_5 + SHA-2Web Crypto APIL'algoritme asimètric més comú. Signa amb la clau privada, verifica amb la clau pública. Per defecte per a la majoria d'IdPs OIDC, passarel·les API i SSO empresarial.
PS256 / PS384 / PS512RSA-PSS + SHA-2Web Crypto APIRSA-PSS és el reemplaçament actualitzat i més segur de RS256. AWS SigV4, AWS Cognito i els proveïdors OIDC moderns tendeixen a preferir-lo. saltLength s'ha d'especificar explícitament.
ES256 / ES384 / ES512ECDSA + P-256/P-384/P-521Web Crypto APISignatures de corba el·líptica. Signatures curtes (ES256 són només 64 bytes), rendiment ràpid, JWTs més petits. Apple Sign in with Apple utilitza ES256 per defecte.
EdDSA (Ed25519)Ed25519 / Ed448Web Crypto APIAlgoritme de signatura d'alt rendiment de nova generació. Signatures deterministes (mateix missatge + mateixa clau sempre produeixen el mateix resultat), sense risc de reutilització de nonce, recomanat per OAuth 2.1.

Output Example

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

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

Header descodificat:
  {
    "alg": "HS256",
    "typ": "JWT"
  }

Payload descodificat:
  {
    "sub": "1234567890",
    "name": "Jane Doe",
    "iat": 1716239022        // 2024-05-20 14:23:42 UTC
  }

Privacy & Security

Aquest banc de treball JWT s'executa 100% al teu navegador, amb el suport de la Web Crypto API nativa del navegador. El token que enganxes, el Header, el Payload, la Signature, el Secret HMAC, qualsevol clau privada RSA/ECDSA, qualsevol parell de claus generat, i cada càlcul de signatura/verificació es queden al teu dispositiu — mai viatgen a un servidor, mai es registren, mai s'analitzen i mai es guarden en memòria cau. La pàgina es pot utilitzar fora de línia un cop carregada. Millor pràctica: mai enganxis tokens de producció de llarga durada o claus privades de producció a cap eina en línia, inclosa aquesta. Aquesta eina és adequada per a depuració, proves d'integració, aprenentatge i generació de tokens de prova — els secrets de producció i les claus privades s'han de gestionar en un entorn local controlat.

Authoritative References

Troubleshooting

Signatura invàlida: 'signature is invalid'

El token i la clau de verificació no coincideixen. Les causes habituals: (1) la clau del servidor i la clau que has enganxat a l'eina són diferents (el més comú); (2) la clau conté caràcters invisibles (espai final, salt de línia, caràcter d'amplada zero); (3) es barregen Base64 i Base64URL; (4) s'ha seleccionat l'algoritme incorrecte (el Header diu HS256, el servidor verifica com RS256, o viceversa). Primer comprova que la clau coincideix byte a byte: para atenció als salts de línia finals del PEM, als espais finals del secret HMAC i als valors `k` del JWK que poden haver estat URL-decodificats erròniament. Confirma que l'algoritme a l'eina coincideix amb el Header.alg del token. Utilitza la funció de decodificació-més-verificació d'aquesta eina per reproduir l'error exacte i confirmar que passa entre 'decodificació correcta' i 'verificació fallida'.

HTTP 401 Unauthorized: Token expirat o iat en el futur

La verificació de signatura ha passat, però `exp` està en el passat (Token expirat), `nbf` encara està en el futur (No abans de), o `iat` és posterior a l'hora actual del servidor (sovint a causa de desviació del rellotge). Un altre cas comú és un `aud` (audiència) que no coincideix: el token es va emetre per a l'App A però el valida l'App B. Utilitza l'àrea de Claims ressaltats d'aquesta eina per detectar l'estat de exp / nbf / iat d'un cop d'ull. exp vermell = expirat, si us plau torna a emetre. nbf vermell = encara no vàlid, comprova si iat és una hora futura. aud vermell = audiència incorrecta, comprova que el servidor tingui configurada l'audiència correcta.

Error d'importació PEM o JWK

PEM té línies en blanc addicionals o li falten marcadors de capçalera/peu (`-----BEGIN PUBLIC KEY-----`); JWK li falten camps requerits (`kty` / `n` / `e` / `kid`); el valor `k` del JWK li falta el farciment Base64URL (ha de tenir farciment `=` o estar estrictament sense `=`); s'està important una clau privada RSA com a clau pública; s'està subministrant una clau privada Ed25519 (llavor de 32 bytes) com a 64 bytes. Torna a exportar un PEM PKIX estàndard amb `openssl rsa -in key.pem -pubout -outform PEM` o `openssl ec -in key.pem -pubout`; per a JWK, utilitza la sortida crua del punt final OIDC Discovery `/.well-known/jwks.json` en lloc de codificar-ho manualment. Aquesta eina detecta automàticament capçaleres PEM, farciment faltant i camps JWK faltants i mostra una indicació.

Fallades de signatura entre RS256 i PS256 entre llenguatges

RS256 utilitza RSASSA-PKCS1-v1_5, PS256 utilitza RSA-PSS. Els dos **no poden verificar-se creuadament** — un token signat amb RS256 per una clau RSA donada sempre fallarà la verificació PS256, i la signatura pot diferir en longitud uns quants bytes. Assegura't que el signant i el verificador utilitzen el mateix algoritme. AWS SigV4 utilitza PS256, la majoria d'IdPs OIDC utilitzen RS256. RSA-PSS també té un paràmetre `saltLength` — OpenSSL per defecte és 32, jose és 32, `rsa.PSSOptions{SaltLength: rsa.PSSSaltLengthEqualsHash}` de Go és l'equivalent correcte. Bloqueja això abans de les proves d'integració entre llenguatges.

Atac alg:none i atac de substitució de clau HS256

El servidor tria un algoritme de verificació basat en l'algoritme declarat al Header del token. Un atacant reescriu la capçalera a `alg: none` (sense signatura) o reescriu un token RS256 a HS256 (utilitzant la clau pública com si fos un secret HMAC compartit) i eludeix la verificació. CVEs històrics com CVE-2015-9235 (jsonwebtoken) i CVE-2022-23529 (múltiples biblioteques Node) es remunten a aquest patró. El servidor ha d'aplicar una llista blanca d'algoritmes — per exemple `algorithms: ['RS256']` — i mai ha de deixar que el token digui al servidor quin algoritme utilitzar. La UI d'aquesta eina mostra tant Header.alg com l'algoritme que has seleccionat realment, i marca les incompatibilitats: això és en si mateix una demostració en viu de 'el client no ha de confiar en Header.alg'.