Estructura de un JWT

Un JSON Web Token son tres segmentos en Base64url unidos por puntos: un header que nombra el algoritmo de firma, un payload con claims sobre quién eres y hasta cuándo, y una firma criptográfica sobre los dos primeros. Definido en RFC 7519, cualquiera puede inspeccionar la estructura — la firma protege la integridad, no el secreto.

Solo local

Cuando un servicio quiere entregarte una prueba de inicio de sesión que cualquiera de sus servidores pueda comprobar sin un almacén de sesiones compartido, te entrega un JWT. El token es una cadena compacta y apta para URLs; seguro que las has visto: tres trozos de aparente galimatías separados por dos puntos, viajando en una cabecera Authorization o en una cookie. El galimatías no es cifrado; es Base64url, y se descodifica en una línea de código.

El formato procede de una familia de especificaciones: RFC 7519 define el token en sí, RFC 7515 (JWS) define cómo lo envuelve la firma, y el grupo de trabajo JOSE aportó los nombres de claims registrados y los identificadores de algoritmos. Ese linaje explica la propiedad más incomprendida del formato, que se expone sin rodeos más abajo — firmar significa que toda manipulación se detecta, no que el contenido sea secreto.

Esta guía descodifica un token real segmento a segmento, enumera los claims registrados con su semántica exacta, compara las dos familias de firma que te encontrarás — HS256 y RS256 — y deja claras las reglas que mantienen los tokens seguros, incluida la razón por la que la verificación pertenece al servidor, con la clave del emisor, en cada petición.

Todo lo que aparece abajo puedes hacerlo con un token real en segundos — el decodificador de JWT divide y descodifica los tres segmentos localmente, y va señalando las marcas de tiempo a medida que avanza.

Como cada segmento está en Base64url, la la guía de Base64 es la lectura complementaria: explica el alfabeto, el padding que se omite y por qué los tokens son aptos para URLs.

Tres segmentos, dos puntos de unión

La serialización compacta es header.payload.signature — cada segmento se codifica por separado en Base64url, con los puntos como separadores literales. La codificación se hace deliberadamente sin padding, así que un token contiene solo letras, dígitos, guiones y guiones bajos: seguro en URLs, cabeceras y cookies sin necesidad de escapar nada. Descodificar los dos primeros segmentos no es ningún truco — es la forma prevista de inspeccionar un token; el tercer segmento es donde ocurre la verificación.

Un token real, con una firma calculada sobre él, se descodifica exactamente así:

Un token con una firma HS256 válida

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJ1c2VyXzg0OTIiLCJhdWQiOiJhcGkuZXhhbXBsZS5jb20iLCJpYXQiOjE3NjcyMjU2MDAsImV4cCI6MTc2NzMxMjAwMCwianRpIjoiYjBmNmMyZDQtNGU3YS00YzFmLTlhMmItM2Q1ZTdmOWExYzNlIn0.iDPqw4BRxZtM064Y3EH83XLB0cgEjbj5snSXeM846VY

Los dos primeros segmentos, descodificados

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

{"iss":"https://auth.example.com","sub":"user_8492",
 "aud":"api.example.com","iat":1767225600,
 "exp":1767312000,
 "jti":"b0f6c2d4-4e7a-4c1f-9a2b-3d5e7f9a1c3e"}

El header: la tabla de contenidos del token

El header es un objeto JSON pequeño — formalmente, el JWS Protected Header. Dos campos hacen casi todo el trabajo: alg nombra el algoritmo de firma y typ registra el tipo de medio, por convención JWT. Un tercero, kid (identificador de clave), indica al verificador qué clave usar cuando el emisor publica varias. El header se firma, pero nunca se cifra, y solo merece confianza cuando la firma se ha verificado — hasta ese momento, alg es un claim, no un hecho.

Campo	Significado	Ejemplo
alg	Algoritmo de firma — la primera decisión de enrutado del verificador	HS256, RS256, ES256
typ	Tipo de medio; JWT por convención, la mayoría de las librerías lo ignora	JWT
kid	Qué clave usar para verificar, cuando se publican varias	2026-01-signing
none	El pseudoalgoritmo que significa «sin firmar» — rechazar salvo que se haya pedido de verdad	(un objetivo de ataque conocido)

El payload: claims registrados y qué promete cada uno

El payload es un objeto JSON de claims. Siete están registrados por RFC 7519 con significados precisos e interoperables; todo lo demás es privado entre el emisor y la audiencia. Los tiempos son valores NumericDate — segundos desde la época Unix, no milisegundos — y los claims de tiempo son orientativos para el verificador: comprobarlos es trabajo del verificador, no algo que el formato imponga.

Claim	Nombre completo	Qué afirma
iss	Emisor	Quién creó y firmó el token — una URL o un nombre
sub	Sujeto	A quién se refiere el token — un identificador de usuario o de cliente
aud	Audiencia	Para qué destinatarios vale el token; los verificadores lo rechazan si no aparecen en la lista
exp	Expiración	Límite en segundos desde la época; inválido en cuanto pasa
nbf	No antes de	El momento más temprano en que el token puede aceptarse
iat	Emitido el	Cuándo se creó el token — prueba de antigüedad, no una caducidad
jti	ID del JWT	Un identificador único para este token — el gancho para las listas de revocación

La firma: HS256, RS256 y cómo funciona la verificación

La firma se calcula sobre la entrada de firma — el header codificado, un punto, el payload codificado — usando el algoritmo que nombra el header. HS256 es HMAC-SHA256 con un secreto compartido: rápida y simétrica, apropiada solo cuando quien firma y todos los verificadores forman un único dominio de confianza, porque cualquiera que tenga el secreto puede fabricar tokens. RS256 es RSA: el emisor firma con una clave privada y cualquiera — incluido un navegador — puede verificar con la clave pública publicada, que es lo que la convierte en la opción por defecto de los protocolos federados como OAuth 2.0 y OpenID Connect.

La verificación recalcula la firma y la compara. Ese es todo el mecanismo — y por eso el alg del header decide por sí solo cómo se ejecuta la comprobación. Las librerías se blindaron tras los ataques de confusión de algoritmos de principios de los años 2010: un token que declara alg none, o un token RS256 reutilizado como HS256 usando la clave pública como secreto HMAC, solo verifica frente a verificadores que no fijan por adelantado el algoritmo esperado.

Las dos familias de un vistazo

HS256: HMAC-SHA256(secret, header + '.' + payload)
       firmante y verificador comparten el secreto

RS256: RSA-SHA256(private key, header + '.' + payload)
       el emisor firma; cualquiera verifica con la clave pública

La regla que se deduce

Fija el algoritmo esperado para cada emisor.
Nunca lo deduzcas solo de la cabecera del propio token.
Nunca aceptes alg: none.

Firmado, no sellado: lo que la firma no hace

La firma demuestra que el token lo emitió quien tiene la clave y que no se ha alterado desde entonces — integridad y autenticidad. No aporta nada de confidencialidad: Base64url es una codificación, y el payload lo puede leer cualquiera que vea el token, incluidas las extensiones del navegador, los proxies cuando los tokens viajan en URLs y los recolectores de logs. De ahí las reglas permanentes: nunca pongas secretos en el payload de un JWT, nunca envíes tokens en URLs y trata cada claim descodificado como un dato, no como una decisión.

Ese último punto es la trampa del lado del cliente. Un navegador puede descodificar un token y leer exp o sub — pero no puede verificar el token de forma significativa, porque no tiene la clave del emisor: con HS256 el secreto jamás debe llegar al navegador, y con RS256 una comprobación en el cliente no prueba nada sobre a qué puede acceder quien lo porta. Los clientes pueden inspeccionar tokens para presentarlos — mostrar un nombre, avisar de la caducidad — pero el servidor debe verificar la firma y todos los claims en cada petición. Inspeccionar no es verificar, y legible no es autorizado.

Inspeccionar tokens con seguridad — el ciclo práctico

Un ciclo de inspección disciplinado tarda segundos: descodifica el header y el payload, comprueba exp y nbf contra el reloj, confirma que iss y aud son lo que esperas, y solo entonces — en el servidor — verifica la firma con un algoritmo fijado de antemano y la clave correcta. Todo salvo la verificación final es procesamiento de texto puro, y por eso un decodificador que se ejecuta por completo en tu navegador es la herramienta adecuada: los tokens reales son credenciales bearer, y las credenciales van en pestañas que controlas tú, no en sitios web que podrían reenviarlas.

Recuerda lo que la estructura no puede darte: revocación — las listas de bloqueo basadas en jti hay que construirlas y consultarlas en el servidor; confidencialidad — usa JWE si necesitas tokens cifrados; y confianza — un token estructuralmente perfecto de un emisor que nunca configuraste no vale nada. La estructura te dice qué se prometió; solo la verificación te dice que la promesa sigue intacta.

Preguntas frecuentes

¿Es seguro pegar mi token real en un decodificador de JWT?

Aquí sí, porque el decodificador de este sitio se ejecuta por completo en tu navegador: el token nunca se sube, ningún servidor podría registrarlo y la Content-Security-Policy del sitio bloquea las peticiones salientes, de modo que la página no puede transmitir nada ni por accidente. Con cualquier decodificador en línea, mucha más cautela — un JWT es una credencial bearer, y quien lo lea puede usarlo hasta que expire.

¿La firma cifra el contenido del token?

No — la firma solo detecta manipulaciones. Base64url es una codificación reversible, no un cifrado: quien tenga el token puede leer todos los claims, y por eso las contraseñas y los secretos nunca deben ir en el payload. Las variantes confidenciales existen como JWE — JSON Web Tokens cifrados — pero los tokens de las cabeceras Authorization corrientes son JWS: firmados, legibles y con detección de manipulaciones.

¿En qué se diferencian HS256 y RS256?

En el modelo de claves. HS256 es HMAC-SHA256 con un único secreto compartido: toda parte capaz de verificar tokens también puede fabricarlos, así que encaja en servicios únicos que controlan los dos extremos. RS256 es RSA: el emisor firma con una clave privada y los verificadores comprueban con una clave pública — verificar nunca concede el poder de falsificar. Los estándares de identidad federada se apoyan en RS256 precisamente por eso.

¿Por qué hay que verificar los JWT en el servidor?

Porque la verificación necesita la clave del emisor y una decisión de autorización, y solo el servidor tiene ambas. Con HS256 el secreto compartido no debe llegar jamás a un navegador; con RS256 un navegador podría comprobar criptográficamente una firma, pero su propia conclusión no prueba nada sobre el acceso — los clientes se pueden modificar. El servidor vuelve a verificar la firma y comprueba iss, aud y exp en cada petición.

¿Qué pasa cuando un JWT expira?

Nada automático — exp es un claim que el verificador debe comprobar. Un servidor conforme la compara con la hora actual y rechaza el token en cuanto pasa; uno descuidado sigue aceptándolo para siempre. Los flujos de refresh existen por eso: tokens de acceso de vida corta comprobados en cada petición, más un token de refresh de vida más larga que el servidor puede revocar cuando haga falta.

¿Puedo fiarme de un token cuya firma no he verificado?

Solo como una pista sin autenticar. Un token no verificado pudo haberlo escrito cualquiera — su iss, su sub e incluso su exp son solo texto hasta que la comprobación de la firma pasa. El modelo mental seguro: descodificar te dice qué afirma el token; verificar te dice quién firmó esos claims y que no han cambiado. Nunca condiciones el acceso a lo primero.

¿Dónde puedo leer las normas citadas aquí?

RFC 7519 — Token web JSON (JWT)
RFC 7515 — Firma web JSON (JWS)

Equipo de ToolsByUs · Cómo comprobamos nuestras herramientas