Decodificar un JWT no és verificar-lo

Un JSON Web Token, o JWT, acostuma a aparèixer com tres cadenes separades per punts. Aquesta forma pot induir una conclusió perillosa: si el navegador pot decodificar les dues primeres cadenes, el seu contingut és fiable. No ho és. Decodificar permet inspeccionar l'estructura declarada; verificar és una decisió de seguretat d'un sistema que coneix l'emissor, l'audiència, el temps, l'algoritme i la clau que espera. Aquesta guia utilitza una mostra forjada i no productiva. No conté cap compte, secret, clau privada ni credencial real.

El problema

RFC 7519 defineix la serialització compacta JWT com tres segments base64url: capçalera, payload i signatura. Base64url és una codificació, no un xifratge. Qualsevol persona amb el token pot llegir els dos primers segments, i un atacant també pot crear-ne uns altres. El payload pot afirmar que un subjecte és administrador, que expira l'any vinent o que prové d'un emissor conegut. Fins que la verificació no acaba bé, són afirmacions aportades per una entrada no confiable.

La distinció és important en qualsevol punt on un token canviï una autorització. Un panell de depuració pot decodificar-lo localment per mostrar una data o un claim mal format. Aquest panell no ha d'usar role, sub o scope per decidir què pot fer algú. Una interfície pot mostrar un avís d'expiració, però una API ha de prendre la seva pròpia decisió, sense acceptar la interpretació d'un navegador. Un token pot ser adequat per a una aplicació i no ser acceptable per a una altra si l'audiència prevista és diferent.

Verificar no és comprovar només que hi ha tres parts. El verificador parteix d'una relació de confiança configurada: accepta pocs algoritmes, aconsegueix una clau per un mecanisme controlat, comprova la signatura sobre les dades protegides originals i avalua els claims segons una política local. RFC 8725 adverteix que el contingut controlat per un atacant no ha d'escollir comportaments crítics de validació. Un decodificador no té aquest context.

Exemple pràctic

Aquest és un token de demostració sintàcticament vàlid. La capçalera es decodifica com {"alg":"HS256","typ":"JWT"}. El payload es decodifica com {"sub":"demo-user","role":"admin","exp":1893456000,"iss":"https://issuer.example.invalid","aud":"demo-api"}. L'últim segment és només el text base64url de la paraula “signature”; no s'ha calculat amb cap secret i no prova res. Està forjat expressament.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkZW1vLXVzZXIiLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE4OTM0NTYwMDAsImlzcyI6Imh0dHBzOi8vaXNzdWVyLmV4YW1wbGUuaW52YWxpZCIsImF1ZCI6ImRlbW8tYXBpIn0.c2lnbmF0dXJl

Un decodificador pot separar el text pels punts, aplicar base64url als dos primers segments i imprimir camps. exp és una NumericDate, segons des de l'època Unix, i es pot convertir a data per inspecció. iss és l'identificador que el token declara com a emissor. aud identifica el destinatari previst. Veure valors plausibles no demostra que l'emissor els hagi creat, que l'API actual en sigui destinatària ni que ara es puguin acceptar.

Canviar demo-user per un altre subjecte, o role de viewer a admin, i tornar a codificar el payload produeix encara tres segments ben formats. També es decodifiquen sense error. Un verificador correcte els rebutja perquè la signatura ja no coincideix amb capçalera i payload sota la clau esperada. L'exemple és útil perquè mostra que l'anàlisi sintàctica funciona abans que s'hagi establert cap confiança.

Procediment

Tracta primer el token com una dada operativa sensible, encara que no sigui una contrasenya. No enganxis un bearer token de producció en una web no aprovada, un tiquet, un xat o una captura. Per diagnosticar localment, utilitza un token de desenvolupament controlat, oculta identificadors o inspecciona'l en l'entorn que l'ha emès. Conserva només el mínim necessari per reproduir el problema: noms i tipus de claims i una conversió d'expiració.

Per inspeccionar, confirma que la forma compacta té exactament tres segments no buits. Decodifica capçalera i payload com JSON UTF-8 sense donar-los autoritat. Anota alg, però no permetis que decideixi la política del servidor. Comprova que exp, nbf i iat tinguin format numèric; compara iss amb l'emissor esperat; i compara aud amb l'identificador del recurs receptor. Són observacions de diagnòstic, no un resultat favorable.

Per autenticar o autoritzar, lliura el token compacte original a un verificador de confiança. Ha de tenir una llista explícita d'algoritmes i tipus de clau acceptats, un emissor configurat i una audiència configurada. Ha de comprovar la signatura abans de dependre del payload, rebutjar expirats amb la seva política de rellotge i aplicar controls de nbf, tipus, subjecte o autorització específica. El descobriment de claus també s'ha d'autenticar i limitar a l'emissor conegut; una capçalera no confiable no pot anunciar un lloc arbitrari de claus.

Després separa validació d'identitat i autorització de l'aplicació. Un token verificat pot establir qui ha emès una afirmació, però l'aplicació encara decideix si aquell subjecte pot fer una acció. Aplica mínim privilegi, regles del servidor i comprovacions del recurs després de verificar. Registra resultats sense guardar bearer tokens sencers. Davant un error, respon de manera genèrica i deixa diagnòstics detallats només en registres protegits.

Explicació tècnica

La signatura es calcula sobre la capçalera i el payload codificats, no sobre l'objecte JSON després que un decodificador el reformati. Això evita que un verificador accepti espais, camps reordenats o segments substituïts. Amb algoritmes simètrics, emissor i verificador comparteixen un secret; amb asimètrics, l'emissor firma amb clau privada i el verificador usa una clau pública autenticada. Poder llegir un payload no implica tenir autoritat per signar-lo.

Els claims són contextuals. RFC 7519 defineix noms registrats, però la política correspon al destinatari. exp indica un moment posterior al qual no s'ha d'acceptar el token, però cada sistema decideix el marge de rellotge. nbf indica inici de validesa. iss requereix comparar exactament amb un identificador configurat, no una semblança visual. aud pot ser una cadena o una llista, i una API ha d'exigir aparèixer-hi. Un claim pot ser sintàcticament correcte i alhora incorrecte per a la petició.

La confusió d'algoritmes explica per què es configura i no s'infereix. Un servei que accepta l'alg anunciat pot ser conduït a una ruta inadequada. Si barreja emissors sense lligar claus, audiències i algoritmes, pot acceptar un token d'un altre domini. RFC 8725 recomana regles excloents per a perfils diferents i comprovació estricta de l'algoritme. Aquestes són responsabilitats del servidor; un decodificador genèric no les coneix.

Errors freqüents

Un error freqüent és tractar el payload decodificat com una sessió. Per exemple, un client llegeix role: admin i mostra una ruta privilegiada abans que el backend verifiqui el token. Ocultar un botó no autoritza, però pot confondre i revelar comportament. Cada operació protegida ha d'exigir autorització al costat de confiança. Un altre error és acceptar exp només perquè és futur: una data futura no repara firma, emissor, audiència o tipus invàlids.

També és un error registrar tokens complets mentre es diagnostica una decodificació. Els bearer tokens poden donar accés fins que expiren, i per tant logs, analítica, informes d'error i extensions es converteixen en exposició. Redacta'ls i no els copiïs en exemples. Un decodificador públic pot ajudar a mirar el format, però no coneix claus privades, emissors aprovats, revocació ni l'API destinatària exacta.

No desactivis la validació de signatura perquè una prova funcioni. Crea un emissor i claus de prova separats, de vida curta i permisos limitats. Rebutja tokens sense firma tret que un format no autenticador dissenyat amb cura els exigeixi; una biblioteca no ha d'acceptar una degradació perquè una capçalera la demani. Prova signatures alterades, audiències inesperades, temps antics i emissors erronis amb la mateixa atenció que el cas correcte.

Consideracions

Defineix els límits de token abans d'escollir biblioteca. Documenta qui emet, quins serveis verifiquen, quines audiències existeixen i com roten les claus. Utilitza audiències diferents per a APIs amb privilegis diferents. Configura exactament l'URI de l'emissor i valida'l de manera consistent. Si hi ha perfils diferents, assigna a cadascun una regla separada en lloc d'una regla permissiva que intenti endevinar la finalitat amb claims opcionals.

El temps requereix cura operativa. Sincronitza rellotges de servidor, estableix un marge petit i documentat i observa fallades que indiquin desviació. Mantén vides d'access token proporcionals al risc i dissenya renovació o revocació fora del decodificador. Veure exp localment pot ajudar a explicar un error, però només la política temporal del verificador decideix acceptació. No suposis validesa perquè una data sembla recent en una altra zona horària.

Evita desar dades decodificades en estat de client innecessari. Una interfície pot necessitar informació no sensible, però el servidor ha de ser l'autoritat per a permisos i recursos protegits. Si un navegador desa un bearer token, l'exposició depèn del model d'amenaces i de l'emmagatzematge; decodificar-lo no la redueix. Una guia no pot escollir l'arquitectura adequada: demana revisió de seguretat en dissenyar un límit d'identitat.

Limitacions

Aquesta guia explica el límit conceptual entre decodificar i verificar. No proporciona una configuració d'autenticació preparada, un disseny de claus ni garanteix que una biblioteca JWT sigui segura si es configura malament. APIs, distribució de claus, perfils de token, emmagatzematge del navegador i requisits d'incidents varien per sistema. Llegeix la documentació actual del verificador i prova'l amb emissor i audiència reals.

JWT no és obligatori per a totes les sessions o APIs. Tokens opacs, sessions de servidor i altres mecanismes tenen compensacions diferents. Una firma vàlida tampoc prova que un usuari estigui autoritzat per a tota acció, que un dispositiu sigui íntegre o que un token no s'hagi revocat externament. Considera la verificació un control necessari dins un disseny més ampli.

Llista de comprovació

Abans de confiar en un JWT, conserva el token compacte original i separa inspecció d'autorització. Decodifica capçalera i payload només per diagnosticar estructura; no prenguis claims visibles com a prova. Verifica la firma en un sistema de confiança amb llista d'algoritmes i origen de claus autenticat. Exigeix emissor i audiència esperats, avalua expiració i not-before amb política temporal documentada i aplica autorització de servidor després. No publiquis ni registris bearer tokens reals, no desactivis la verificació per comoditat i prova signatures i claims modificats com a casos negatius. Consulta RFC 7519 i RFC 8725 amb la documentació actual de la biblioteca.