¿Qué es un JSON Web Token (JWT)?

Un JSON Web Token es un token compacto y seguro para URLs que transporta claims JSON firmadas, y permite verificar solicitudes sin sesiones almacenadas. Ese es el encuadre del propio RFC 7519 — “un medio compacto y seguro para URLs de representar claims que se transfieren entre dos partes” — y las dos ideas que contiene cargan con todo lo que sigue: el token contiene sus hechos, y una firma hace que esos hechos sean comprobables por cualquiera que tenga la clave correcta, sin base de datos de por medio.

Puntos clave

Un JWT, decodificado

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiJ1c3ItOGZrMiIsInJvbGUi… . dBjftJeZ4CVP…

header     { "alg": "HS256", "typ": "JWT" }
payload    { "sub": "usr-8fk2",  "role": "editor",
             "iss": "https://api.example.com",  "aud": "example-web",
             "iat": 1767024900,  "exp": 1767025800 }        ← vida de 15 minutos
signature  HMACSHA256( base64url(header) + "." + base64url(payload), secret )

Cualquiera puede DECODIFICAR las dos primeras partes — Base64Url es empaquetado, no cifrado.
Solo quien tiene la clave puede FORJAR la tercera — y ese es todo el truco.

El contraste que vale la pena ver en código — la alternativa con estado contra la que se mide cada decisión de JWT:

// JavaScript / Node.js — Back4app JS SDK
// The stateful contrast: Back4app issues revocable session tokens
const user = await Parse.User.logIn('ada', 'correct-horse-battery');
const token = user.getSessionToken(); // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
await Parse.User.logOut(); // token invalid NOW — no waiting for an exp claim

// Flutter / Dart — Back4app Flutter SDK
// The stateful contrast: Back4app issues revocable session tokens
final user = ParseUser('ada', 'correct-horse-battery', null);
await user.login();
final token = user.sessionToken; // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
await user.logout(); // token invalid NOW — no waiting for an exp claim

// iOS / Swift — Back4app Swift SDK
// The stateful contrast: Back4app issues revocable session tokens
let user = try await User.login(username: "ada", password: "correct-horse-battery")
let token = user.sessionToken // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
try await User.logout() // token invalid NOW — no waiting for an exp claim

// Android / Kotlin — Back4app Android SDK
// The stateful contrast: Back4app issues revocable session tokens
val user = ParseUser.logIn("ada", "correct-horse-battery")
val token = user.sessionToken // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
ParseUser.logOut() // token invalid NOW — no waiting for an exp claim

Cómo funciona la verificación

Una precisión que los explicadores se saltan: “JWT” nombra el formato de claims; lo que todo el mundo pasa de mano en mano es en realidad un JWS (RFC 7515) — la serialización firmada — mientras que JWE es el hermano cifrado para payloads que deben permanecer ilegibles. Y la verificación son dos trabajos, no uno: comprobar la firma y luego validar las claims — exp y nbf contra el reloj, iss contra tu allowlist de emisores, aud contra el identificador de este servicio. Un token perfectamente firmado que está expirado, viene del emisor equivocado o fue acuñado para otra audiencia es un ataque perfectamente firmado.

Claims: el vocabulario del payload

Mantén los payloads magros por partida doble: los tokens viajan en cada solicitud como headers (las cookies topan cerca de los 4 KB, y cada claim es ancho de banda repetido), y todo lo que llevan es legible para quien tenga el token.

JWT vs. tokens de sesión

La verdad pasada de moda con la que ahora abren varias guías de buenas prácticas: para una app renderizada en el servidor con un solo backend, las sesiones del framework son más simples y más controlables — los JWTs se ganan su lugar cuando los tokens deben verificarse entre servicios o por partes que no deberían llamar a casa en cada solicitud.

El problema de la revocación, con honestidad

La ausencia de estado (statelessness) es la incapacidad de revocar — la misma propiedad, descrita dos veces. Un token firmado es válido hasta exp sin importar lo que haya pasado desde entonces: logout, cambio de contraseña, baneo de la cuenta. Toda solución reintroduce estado, así que elige el sabor: una denylist basada en jti + iss (la construcción recomendada por OWASP) consultada por solicitud — poco estado, pero estado; el versionado de claves, que revoca a todos a la vez; o la arquitectura estándar — access tokens de vida corta (5–15 minutos) más refresh tokens revocables con rotación: cada refresh emite un refresh token nuevo y retira el anterior, así uno robado muere en el primer replay, y el reúso de un token retirado delata el robo y mata a toda la familia de tokens. La latencia de revocación pasa a ser igual a la vida del access token — que es la verdadera razón de que esas vidas sean cortas.

Elegir un algoritmo — y los ataques a esa elección

La sección de ataques por la que existe el RFC 8725, en tres frases. alg: "none" es un valor legal del header — las bibliotecas que lo honran aceptan tokens sin firma. El ataque de confusión: a un verificador que deja que el header del token elija el algoritmo se le puede entregar un token “HS256” firmado con la clave RSA pública del servidor usada como secreto HMAC — un valor público usado como privado. Ambos mueren de la misma manera: el verificador fija sus algoritmos y claves aceptados en la configuración y jamás confía en el header para elegir.

Dónde guardar los JWTs en el navegador

El modelo de amenazas, no el folclore: localStorage cambia inmunidad a CSRF por robo vía XSS, las cookies cambian lo inverso — por eso el consenso parte la pareja: access token en memoria, refresh token en una cookie endurecida.

Casos de uso comunes

• Autenticación de APIs — el bearer token detrás de los headers Authorization en APIs REST y GraphQL.
• Identidad en microservicios — un token emitido por el gateway y verificado de forma independiente por cada servicio, sin almacén de sesiones compartido.
• ID tokens de OpenID Connect — la afirmación de identidad firmada en cada login social — siempre un JWT.
• Traspasos entre sistemas — enlaces firmados, payloads de webhooks, permisos de descarga: claims verificadas por una parte que no puede devolverte la llamada.
• Pistas de autorización stateless — roles y IDs de tenant transportados en claims, con la verificación autoritativa todavía del lado del servidor.

¿Deberías usar JWTs o sesiones? Matriz de decisión

Limitaciones y trade-offs

• La irrevocabilidad es estructural. Cada mitigación — denylists, vidas cortas, rotación — es una devolución parcial del estado que quitaste; ponle precio antes de elegir stateless.
• Las claims se vuelven obsoletas. Los roles son una foto del momento de emisión; un admin degradado sigue siendo admin hasta la expiración. Las vidas cortas acotan la ventana de obsolescencia.
• El payload es público. Trátalo como legible por el usuario y por cualquier ladrón de tokens — identificadores sí, secretos y PII no.
• Los defaults de las bibliotecas han quemado gente. Fijar algoritmos, validar claims y comprobar typ son responsabilidades de tu configuración, no garantías de la biblioteca.
• El tamaño se acumula. Cada claim viaja en cada solicitud; los payloads generosos gravan el ancho de banda móvil y pueden desbordar los límites de las cookies.

Tokens en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. La elección de la propia plataforma ilustra la matriz de decisión: las sesiones de cliente usan tokens de sesión revocables del lado del servidor — las pestañas de código de arriba — de modo que el logout, los cambios de contraseña y la terminación de sesiones desde el dashboard surten efecto de inmediato, sin ventana de expiración que esperar. Los JWTs aparecen donde corresponden: los ID tokens OIDC de los proveedores de identidad se verifican del lado del servidor mediante adaptadores de auth durante el login social, y las funciones de Cloud Code pueden acuñar o verificar JWTs para traspasos con terceros usando bibliotecas estándar — con el secreto de firma en la configuración del servidor, nunca enviado a los clientes. Con estado donde importa el control, stateless en los bordes donde la verificación debe viajar: la arquitectura por la que aboga este artículo, preensamblada.