1 · Tres piezas, dos decisiones
Un JWS habitual tiene header.payload.signature. La firma permite comprobar integridad y emisor cuando se valida con la clave correcta. Después queda una segunda decisión: si esas claims son válidas para esta API, este momento y esta operación. Decodificar no es validar.
{ "iss": "https://id.example", "sub": "usr_42", "aud": "api-academia", "exp": 1787600000, "scope": "guides:read" }2 · Cada claim limita el contexto
iss: emisor exacto que la API confía.aud: destinatario; evita reutilizar un token válido de otro servicio.expynbf: ventana temporal con tolerancia de reloj pequeña y explícita.sub: identidad estable; no sustituye la autorización sobre un recurso.jti: identificador útil para revocación o protección frente a repetición.
3 · Valida con una política fijada por el servidor
La API decide de antemano algoritmos permitidos, emisor, audiencia y tipos de token. Nunca toma esa política del propio token. Rechaza firmas ausentes, algoritmos no permitidos, claves de tipo incorrecto, claims obligatorias ausentes y tokens fuera de ventana. Después aplica autorización server-side al recurso.
verifySignature(token, allowedAlgorithms, trustedKeys)requireExactIssuer(token, expectedIssuer)requireAudience(token, expectedAudience)requireTimeWindow(token, now, smallClockSkew)authorize(token.sub, action, resource)4 · Diseña rotación y revocación antes del incidente
Separa claves por entorno y propósito. Publica claves públicas mediante JWKS cuando corresponda, identifica cada una con kid y acepta la anterior solo durante una transición acotada. Protege la clave privada en un gestor de secretos. Usa access tokens breves y un mecanismo explícito de renovación y revocación.
5 · En el navegador, almacenamiento y envío son parte del modelo
Un token en almacenamiento accesible a JavaScript queda expuesto ante XSS. Una cookie HttpOnlyreduce esa exposición, pero exige protección CSRF, Secure, SameSite adecuado y un alcance de dominio y ruta mínimo. No existe una ubicación universalmente segura: decide según arquitectura.
Checklist de implementación
- Algoritmos, issuer y audience están en configuración del servidor
- La firma se valida antes de usar cualquier claim
- Expiración, nbf y claims obligatorias se comprueban
- La autorización del recurso ocurre server-side
- Rotación, revocación y respuesta ante fuga están documentadas
- Los logs no almacenan el token completo
Glosario
JWT
Formato compacto para transportar claims firmados entre partes; no implica cifrado por defecto.
Claim
Afirmación incluida en el token, como sujeto, emisor, audiencia o expiración.
Firma
Prueba criptográfica de integridad y autenticidad calculada sobre el contenido del token.
Audience (aud)
Claim que identifica qué servicio o destinatario debe aceptar el token.
Rotación de claves
Sustitución controlada de claves para limitar exposición sin interrumpir validaciones legítimas.