Decodificador, Verificador i Generador JWT
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "1234567890",
"name": "John Doe",
"admin": true,
"iat": 1516239022
}sub· Subjecte1234567890name· NameJohn Doeadmin· Admintrueiat· Emès a1516239022→ 18/01/2018 09:30:22algHS256HMAC (simètric)typ· TypeJWTBanc 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
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.
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
Com usar-ho
- 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
- Selecciona l'algoritme: canvia entre HS256 / RS256 / ES256 / PS256 / EdDSA; l'eina infereix del Header.alg i marca qualsevol incompatibilitat
- 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
- 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
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
}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
Exemples de codi
50 línies de Node.js: signatura i verificació HS256 escrita a mà
javascriptDestil·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')) // falseCostat del navegador: Web Crypto API per a signatura HMAC
htmlLa 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)
javascriptUtilitza 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
pythonLa 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'])Comparació de 5 tipus d'algoritmes de signatura JWT: quin triar?
JWT no és un sol algoritme — 5 famílies d'algoritmes ofereixen compromisos diferents en claus, rendiment, seguretat i compatibilitat. Avalua primer l'escenari i després tria l'algoritme; t'estalviarà molts maldecaps.
| Algoritme | Tipus | Clau | Rendiment | Escenaris típics | Atencions |
|---|---|---|---|---|---|
HS256 | HMAC simètric | Mateix Secret | Molt ràpid | Dins del clúster de serveis, entorn de confiança, aplicacions monolítiques | El Secret no ha de filtrar-se al verificador; mínim 32 bytes aleatoris |
RS256 | RSA asimètric | Clau privada signa / clau pública verifica | Mitjana | OIDC, passarel·les API, SSO empresarial, quan cal separar clau pública i privada | Utilitza RSASSA-PKCS1-v1_5; cal fixar el padding entre llenguatges |
PS256 | RSA-PSS asimètric | Clau privada signa / clau pública verifica | Mitjana | AWS SigV4, AWS Cognito, IdPs OIDC moderns | Cal fixar explícitament saltLength (OpenSSL/jose=32, Go=longitud del hash) |
ES256 | ECDSA asimètric | Clau privada signa / clau pública verifica | Ràpid + signatura curta | Apple Sign in with Apple, mòbil, ample de banda baix | Les corbes diferents (P-256/P-384/P-521) han de coincidir amb el servidor |
EdDSA | Ed25519/Ed448 | Clau privada signa / clau pública verifica | Molt ràpid (signatura determinista) | OAuth 2.1, protocols nous, verificació d'alta freqüència | Web Crypto admet Ed25519; Ed448 encara no està activat a totes les plataformes |
Best Practices
No enganxis mai el Secret / clau privada de producció a cap eina en línia
Tot i que aquesta eina processa el 100% localment al navegador (no penja cap token ni clau), un flux de depuració consolidat fàcilment porta que més endavant, per costum, el Secret / clau privada / Access Token de llarga durada de producció s'enganxi per error a una eina en línia desconeguda o es filtri per captures de pantalla. Els tokens de llarga durada (Refresh Token, clau privada de producció, API Key) s'han de gestionar en un entorn local controlat; aquesta eina només serveix per depurar Access Tokens de curta durada, parells de claus de prova per a la integració i aprendre l'estructura del JWT.
OWASP JSON Web Token Cheat SheetEl servidor ha d'aplicar una llista blanca d'algoritmes, mai confiar en Header.alg del Token
L'atac alg: none (CVE-2015-9235, etc.) i l'atac de substitució HS256 (usar la clau pública com a Secret per enganyar el servidor RSA) provenen que el servidor escull la lògica de verificació segons l'algoritme declarat al Header. El codi de producció ha de codificar de manera fixa la llista blanca d'algorithms, per exemple `algorithms: ['RS256']`, i prohibir que el Token decideixi quin algoritme fer servir. Durant la depuració, si Header.alg no coincideix amb el que espera el servidor, sospita primer de la configuració del servidor, no del contingut del Token.
El Secret HS256 ha de ser un nombre aleatori de com a mínim 32 bytes
HS256 utilitza HMAC-SHA256; una longitud de clau inferior a la longitud del resum (32 bytes) redueix significativament el cost de força bruta. No facis servir cadenes curtes com 'my-secret' o 'password123', no concatenis el nom del servei, de l'empresa o l'any. La forma estàndard: genera amb `openssl rand -base64 32` o `crypto.randomBytes(32).toString('base64url')`, desa'l a variables d'entorn / KMS / servei de gestió de claus, i mai l'escriguis al codi.
Puc guardar dades sensibles en un JWT?El JWT de producció ha de validar exp / nbf / iat / iss / aud, no només la signatura
Que la signatura passi només demostra 'no s'ha manipulat', però no 'encara no ha expirat', 'realment l'ha signat aquest IdP' o 'realment s'ha emès per a aquesta aplicació'. L'entorn de producció ha de validar obligatòriament exp (expiració), nbf (inici de validesa), iat (emissió), iss (emissor), aud (audiència) — tots els Claims rellevants, sense saltar-ne cap. OWASP enumera explícitament aquests 4-5 punts com a obligatoris. Validar només la signatura sense comprovar el temps és l'arrel de moltes filtracions de tokens (refresh token que no expira mai).
Expiració dels tokens en capes: Access 15-30 minuts, Refresh 7-30 dies
L'Access Token s'encarrega de les crides a l'API: com més curta l'expiració, més segur (un cop filtrat deixa de ser vàlid ràpid); el Refresh Token s'encarrega de canviar l'Access Token, pot ser més llarg però ha d'estar emmagatzemat al servidor i poder ser revocat. Valors habituals d'experiència: Access 15-30 minuts, Refresh 7-30 dies, combinat amb Refresh Token Rotation (cada vegada que es fa servir un Refresh per canviar un Access, alhora s'emet un Refresh nou i l'antic queda invalidat immediatament) — equilibra la detecció de filtracions i l'experiència d'usuari.
Sense estat vs amb estat: el JWT no substitueix la Sessió
El JWT empaqueta l'estat dins del Token, dóna suport natural a l'escalat horitzontal de microserveis i al CORS entre dominis, però el cost de revocació és alt (cal una llista negra o expiracions curtes). La Sessió desa l'estat a Redis/BD al servidor, pot 'expulsar l'usuari' però requereix emmagatzematge compartit. **No és triar un dels dos**: Access JWT de curta durada + registre de sessió del Refresh Token al servidor és la solució híbrida més habitual, que combina l'escalat sense estat i la revocació instantània. Els sistemes financers/administratius que requereixen revocació instantània han d'anar amb compte amb el JWT pur.
Puc guardar dades sensibles en un JWT?El Payload és text pla per defecte, no hi fiquis dades sensibles
El JWT (JWS) no xifra el Payload per defecte; qualsevol que tingui el Token pot descodificar-lo amb Base64URL i llegir-ne el contingut. **Mai de la vida** posis al Payload contrasenyes, números d'identitat nacional, números de targeta de crèdit, claus API, Access Tokens ni Refresh Tokens. El JWT és adequat per a Claims no sensibles (ID d'usuari, rol, expiració, ID de llogater); les dades sensibles les ha de consultar el servidor via sub. Si necessites xifrar el Payload, fes servir JWE (RFC 7516), però és 2-5 vegades més lent i afegeix complexitat de gestió de claus — prioritza l'esquema 'Claim no sensible + consulta al servidor'.
Què és un JWT?A RSA-PSS (PS256/PS384/PS512) en la integració entre llenguatges, fixa primer saltLength
RS256 i PS256 no es poden verificar creuadament (fan farciment diferent), i PS256 té una altra trampa: el paràmetre `saltLength`. OpenSSL per defecte és 32 bytes, Node jose per defecte 32 bytes, Python PyJWT per defecte igual a la longitud del hash (SHA-256=32), Go per defecte `rsa.PSSSaltLengthEqualsHash`. A la integració entre llenguatges, fixa primer el mateix valor (recomanat 32 bytes); si no, un Token PS256 signat amb el mateix parell de claus RSA no passarà la verificació entre llenguatges.
Fallades de signatura entre RS256 i PS256 entre llenguatgesFlux de depuració: utilitza parells de claus de prova, no toquis la producció
Durant la integració o el desenvolupament local, genera primer un parell de claus de prova completament nou (HS256 — Secret aleatori, RS256/ES256/EdDSA — parell de claus generat amb un sol clic per l'eina); mai reutilitzis la clau privada de l'IdP de producció ni el Secret del domini de l'empresa. Un cop acabada la depuració o les proves locals, destrueix immediatament les claus de prova. La funcionalitat 'Generar parell de claus' d'aquesta eina està dissenyada exactament per a això: RSA-2048/4096, P-256/P-384, Ed25519 es generen amb un sol clic i es poden utilitzar a l'instant; quan s'acaba la integració es poden llençar directament.
Genera JWTs de prova durant la integració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).
Solució de problemes
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'.
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.
Supported Video Formats
| Format | MIME | Browser support | When to use |
|---|---|---|---|
| HS256 / HS384 / HS512 | HMAC + SHA-256/384/512 | Universal | Algoritme 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 / RS512 | RSASSA-PKCS1-v1_5 + SHA-2 | Web Crypto API | L'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 / PS512 | RSA-PSS + SHA-2 | Web Crypto API | RSA-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 / ES512 | ECDSA + P-256/P-384/P-521 | Web Crypto API | Signatures 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 / Ed448 | Web Crypto API | Algoritme 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. |
Authoritative References
- Comparació Segura de Text
- Conversió Binària
- Xifrat de César
- Codi Morse
- Codificació Hexadecimal
- Base64 a Vídeo
- Imatge a Base64
- Base64 a imatge
- Text a Base64
- Base64 a Text
- Verificador de hash de fitxer
- Fitxer a Base64
- Base64 a Fitxer
- Àudio a Base64
- Base64 a Àudio
- Xifrar i desxifrar AES
- Xifratge i Desxifrat DES
- Codificador i Descodificador Base32
- Base58 Codificació i descodificació
- Codificació Base64
- Descodificació Base64
- Comparació Base64
- Divisor Base64
- Base64 fusió de múltiples línies
- Formateig Base64
- Validació Base64
- Codificació Base64 per lots
- Descodificació per Lots Base64
- Neteja Base64
- Gestió del padding Base64
- Estadístiques Base64
- Base64 a Hex
- Convertidor Base64 DataURL
- Convertidor Base64-Hex
- Codificació Base85
- Generació i Verificació HMAC
- Derivació PBKDF2
- Hash MD5
- Hash SHA-256
- Hash SHA1
- Hash SHA512
- Decodificador, Verificador i Generador JWT
- Codificació d'Entitats HTML
- Unicode Escape
- Codificació URL
- Base64 URL-Safe
- MIME Base64
- Ofuscació de Java
- Ofuscació JS
- Ofuscació de PHP
- Ofuscació de Python
- Convertidor de Vídeo a Base64