JWT: estructura y vulnerabilidades

1) Qué es JWT y dónde se utiliza

JWT es un contenedor de afirmaciones autosuficiente compacto (claims) en formato 'Base64Url (header). Base64Url(payload). Base64Url(signature)`.

• JWS (tokens firmados - autenticidad/integridad),
• JWE (tokens cifrados - privacidad),
• OIDC/OAuth2 como tokens de acceso/ID, así como autenticación de servicio a servicio.

Ventajas: autonomía, capacidad de almacenamiento en caché, pequeños gastos generales. Contras: riesgo de validación incorrecta, casos complejos de revocación.

2) Estructura JWT

2. 1 Título (titular, JSON)

Mínimo: algoritmo e ID de clave.

json
{ "alg": "ES256", "kid": "jwt-2025-10", "typ": "JWT" }

'alg': algoritmo de firma/cifrado (RS256/ES256/PS256/HS256, etc.).
'kid': puntero de clave (para rotación JWKS).
Fuentes de claves opcionales: 'jku', 'x5u' (ver vulnerabilidades § 6. 3).

2. 2 Carga útil (payload, JSON)

• `iss` (issuer), `aud` (audience), `sub` (subject)
• 'exp' (tiempo de caducidad), 'nbf' (no antes), 'iat' (emitido)
• 'jti' (ID de token, apto para revisiones)
• marcas de dominio: 'scope/roles', 'tenant', 'kyc _ level', etc.

2. 3 Firma (signature)

JWS = `sign(base64url(header) + "." + base64url(payload), private_key)`

Verificación: estrictamente la clave pública correspondiente y exactamente el algoritmo que el servidor espera.

3) Invariantes básicos de verificación

1. El algoritmo es capturado por la configuración del servidor de recursos (allow-list) en lugar de confiar en el contenido de 'header. alg`.
2. Comprobar 'iss' y' aud 'para la coincidencia exacta,' amb/nbf '- teniendo en cuenta el pequeño' clock _ skew '(± 30-60s).
3. Rechazar tokens sin 'kid' sólo si la única clave y no hay rotación; de lo contrario, requerir 'kid'.
4. No confiar en ningún sello sin autorización a nivel de objeto (BOLA-first).
5. Parcing - después del cryptoprover; comprobaciones básicas de tamaño antes de la decodificación.

4) JWS vs JWE

JWS: firmado, pero leemos. No coloque en payload PII/secretos.
JWE: cifra payload; más difícil de integrar, el modelo clave es crítico.
En la mayoría de las API, la prohibición de datos sensibles en payload es suficiente para JWS +.

5) Ciclo de vida del token

Acceso: tiempo corto (5-30 minutos).
Refresh: más largo (7-30 días), rotate-on-use (desechable), almacena la «lista negra» de 'jti/sid'.
Revocación: listas 'jti' con TTL, introspección para tokens de opaque, reducción de 'amb' en incidencias.
Rotación de claves: JWKS con superposición (antiguo + nuevo), consulte el artículo «Rotación de claves».

6) Vulnerabilidades frecuentes y cómo cerrarlas

6. 1 'alg = none '/reemplazo del algoritmo

Esencia: el servidor confía en el campo 'alg' y acepta un token sin firmar.
Protección: allow-list de algoritmos rígidos en el servidor; rechazar 'ninguno' y valores inesperados.

6. 2 RS256→HS256 swap (simetrización)

Lo esencial: el atacante sustituye el 'alg' por el HS256 y utiliza la clave pública como secreto HMAC.
Protección: vincular la clave al algoritmo por configuración; no mezclar proveedores simétricos/asimétricos en un solo 'kid'.

6. 3 Inyección de llaves ('kid/jku/x5u')

• 'jku' apunta a un JWKS controlado por el atacante (deslizará su llave).
• 'x5u '/' x5c' abuso de certificados externos.
• 'kid' con inyección de vía/SQL ('../../privkey. pem 'o' 'OR 1 = 1 --').

• Ignore los 'jku/x5u' remotos o filtre por una lista de dominios estricta.
• 'kid' sólo se utiliza como clave en el directorio local (tabla/caché), sin rutas de archivos/concatenaciones SQL.
• JWKS enviar desde URL de confianza, TTL corto, firma/pinning canal.

6. 4 Secretos débiles HS256 (fuerza bruta)

Esencia: El secreto HMAC es corto/pato → sustitución de firma.
Protección: utilizar asimetría (RS/ES/PS) o longitud de secreto ≥ 256 bits, secretos sólo en KMS.

6. 5 Adhesivos ausentes/no inválidos

No hay 'aud '/' iss'/' amb' → el token de servicio cruzado es adecuado o infinito.
Demasiado largo 'amb' → el riesgo de comprometer.
Protección: requerir un conjunto completo de los estigmas, 'amb' corto, 'nbf '/' iat' validar con 'clock _ skew'.

6. 6 Replay y robo de token

Esencia: interceptación/repetición de token (fugas en logs, XSS, MitM sin TLS).

• TLS везде, `Secure`+`HttpOnly` cookie, SameSite=Lax/Strict.
• DPoP/PoP (enlace de token a clave de cliente) y/o mTLS para socios.
• Corto 'amb', refresh-rotation, device-binding.

6. 7 Fugas a través de XSS/almacenamiento

En esencia: el almacenamiento JWT en 'localStorage '/' sessionStorage' → está disponible por JS.
Protección: almacenar tokens de acceso en HttpOnly-cookie (si es posible un modelo de cookie) + CSP estricto/Tipos de confianza.
Para un SPA sin cookies: aísle el token en la memoria, viva mínimamente, proteja contra XSS.

6. 8 CSRF

Esencia: durante las sesiones de cookies, solicitudes de un sitio web de terceros.
Protección: SameSite, anti-CSRF tokens (doble submit), 'Origin/Referer' validación, filtros Fetch-Metadata.

6. 9 Sobredimensionamiento/abuso de tamaño

El fondo: enormes payload/encabezados, DoS en el estacionamiento.
Protección: límites de tamaño de título/cuerpo, early-reject 431/413, juego de etiquetas de fix.

6. 10 Reemplazo 'typ '/' cty'

Esencia: confusión de tipos ('typ: "JWT'), objetos JOSE anidados.
Protección: ignorar 'typ/cty' por seguridad, confiar en algoritmos fijos y un esquema de estigmas.

7) Almacenamiento y transferencia de tokens

7. 1 API de servidor (machine-to-machine)

mTLS/HMAC, preferiblemente asimetría para JWT, canales - vía mesh.
Almacén de claves - KMS/HSM, rotación programada, JWKS con superposición.

7. 2 Clientes del navegador

HttpOnly Secure Cookie для access/refresh; TTL cortos; actualización - a través de «silent refresh» con 'SameSite = None' sólo bajo HTTPS.
CSP estricto, tipos de confianza, protección contra XSS; para SPA: no almacenar un token en el disco siempre que sea posible.

8) JWKS, rotación y revisión

JWKS es publicado por el autorizador; los consumidores acumulan durante 5-15 minutos.
Plan de rotación: añadir un nuevo 'kid' → empezar a firmarlo → después de N días eliminar el antiguo de JWKS → purge.
Reseña: listas 'jti/sid' c TTL; en el caso de un incidente, acortar temporalmente el 'amb' y el force-logout (invalidar el refresh).

9) Multi-tenant y minimización de datos

Incluir 'tenant '/' org' en el token sólo si es necesario por arquitectura; de lo contrario, apriete los atributos de PDP por 'sub'.
Ningún PII; un conjunto mínimo de estigmas → menos riesgo de fugas y corolación.

10) Lista de validación práctica (servidor de recursos)

• Parsim sólo después de comprobar la firma y los límites de tamaño subyacentes.
• 'alg' de la configuración; rechazar los inesperados.
• Comprobar 'iss' ∧ 'aud' ∧ 'exp' ∧ 'nbf' ∧ 'iat' (con 'clock _ skew').
• Comprobar 'kid' por directorio local/JWKS (TTL corto).
• Filtrar/normalizar los punteros externos ('jku/x5u' es solo allow-list).
• Limitar la longitud/composición de los estigmas (esquema).
• Aplicar autorización de objeto a un recurso (BOLA-first).
• Lógica 'kid', 'sub', 'aud', 'iss',' jti ',' amb ',' tenant ',' trace _ id '(sin PII).
• Métricas de errores de firma, retraso, auditoría de rotación.

11) Ejemplos de políticas seguras (pseudo)

11. 1 Configuración de expectativas del algoritmo

yaml jwt:
expected_issuer: "https://auth. example. com"
expected_audience: ["wallet-service"]
allowed_algs: ["ES256"] # fix the jwks_url: "https ://auth. example. com/.well-known/jwks. json"
jwks_cache_ttl: 600s clock_skew: 60s required_claims: ["iss","aud","sub","exp","iat"]

11. 2 Renuncia a la remota 'jku/x5u'

yaml reject_untrusted_key_sources: true allowed_jku_hosts: ["auth. example. com"] # if absolutely necessary

11. 3 Lista de retroalimentación de ejemplo (Redis)

pseudo if redis. exists("revoke:jti:" + jti) then deny()
if now() > exp then deny()

12) Observabilidad y fuerza

Метрики: `jwt_verify_fail_total{reason}`, `jwt_expired_total`, `jwks_refresh_total`, доля `kid`.
Logs (estructurados): 'iss/aud/sub/kid/jti/amb/tenant/trace _ id', causa del fallo.
Dashboards: «caducando pronto», una oleada de errores de validación, distribución por regiones/clientes.
Alertas: crecimiento de 'verify _ fail' (firma/algoritmo), errores JWKS, proporción de tokens caducados.

13) Antipatternas

Confiar en 'alg' del token; mantener 'ninguno'.
Tokens de acceso de larga vida y ninguna rotación refresh.
HS256 con un secreto corto/secreto en ENV sin KMS.
Aceptar 'jku/x5u' desde cualquier dominio; cargar dinámicamente JWKS sin allow-list.
Poner PII/secretos en el payload JWS.
Almacenar tokens en 'localStorage' si hay riesgos XSS.
Silenciar errores de validación (devolver 200 con «error suave»).
Falta de comprobaciones de BOLA y solo confiar en 'scope/role'.

14) Especificidad de iGaming/finanzas

Los estigmas son: 'kyc _ level', 'risk _ tier', 'tenant', rigurosos 'aud'.
TTL cortos para operaciones de escritura (depósitos/retiros), PoP/DPoP o mTLS para rutas críticas.
Auditoría regulatoria: registros de entradas/fallas inmutables, almacenamiento de registros dentro de los límites de la región.
Los socios/PSP tienen claves individuales/' aud ', claves de PE-tenant y JWKS individuales.

15) Lista de comprobación prod

• La lista rígida de algoritmos; 'none' está prohibida.
• 'iss/aud/amb/nbf/iat/jti' se verifican; los cortos 'amb'.
• JWKS con superposición, caché TTL corta; monitoreo de fracciones 'kid'.
• Refresh — rotate-on-use; listas 'jti/sid' con TTL; un playbook de reseñas.
• PoP/DPoP o mTLS en rutas críticas.
• Cookies HttpOnly para navegador, Tipos CSP/Trusted vs XSS; Protección CSRF.
• Sin PII en payload; un conjunto mínimo de estigmas.
• Métricas/registros de validación y fallos; alertas JWKS/verify_fail.
• Pruebas de escenarios negativos: RS→HS swap, 'kid' -inyecciones, 'jku' spoofing, oversize, clock-skew.

16) TL; DR

Fije el algoritmo y las claves en el lado del servidor, desconfíe del 'alg' del token, requiera 'iss/aud/amb/nbf/iat/jti'. Gire las llaves a través de JWKS con solapamiento, mantenga los tokens cortos y refresh desechables. Almacenar los tokens de forma segura (HttpOnly-cookie para webs), minimizar los estigmas, no poner PII. Cierre los 'jku/x5u/kid' -vectores, evite HS256 con secretos débiles, agregue PoP/DPoP o mTLS en rutas críticas y siempre haga comprobaciones de BOLA al nivel de recurso.