JWT: firma, cifrado y claims, 6 ejercicios resueltos para TAI
Respuesta rápida: Base64URL no cifra. Un JWS aporta integridad mediante firma o MAC; un perfil que exige
iss,audyexpdebe validarlos además. Si se necesita confidencialidad del contenido, se usa JWE.
Tres nombres que no son sinónimos
El RFC 7519 define JWT como una forma compacta de transportar claims. Puede estar protegido como JWS, que usa firma o MAC, o como JWE, que cifra. Un ejemplo ficticio como eyJ... no contiene un secreto por parecer opaco: su cabecera y carga pueden estar simplemente codificadas en Base64URL.
| Mecanismo | Propiedad principal |
|---|---|
| Base64URL | Representación transportable, reversible |
| JWS | Integridad mediante firma o MAC |
| JWE | Confidencialidad del contenido para su destinatario |
Seis ejercicios
1. Carga legible
Una aplicación decodifica la segunda parte de un token y lee {"sub":"usuario-ficticio"}. ¿Prueba que está cifrado? No. Base64URL permite representar bytes; no oculta el contenido. La respuesta correcta no depende de que el identificador sea real o ficticio.
2. Cambiar una audiencia
Un atacante altera aud en un JWS ya protegido. ¿Puede conservar una protección válida? No, salvo que controle la clave o exista un fallo de validación. La firma o MAC cubre el contenido protegido; cambiar el payload invalida la comprobación.
3. Firma sin autorización
Un JWS válido con HS256 tiene iss: "emisor-ejemplo". ¿Concede automáticamente permisos de administrador? No. Un MAC usa clave compartida y no prueba un emisor único; cualquier parte que la conozca puede generarlo. La aplicación debe permitir el algoritmo esperado, excluir alg: none, confiar en la clave y aplicar autorización propia.
4. exp vencido
En un perfil que exige exp, este representa una fecha pasada. ¿Debe aceptarse porque iss es correcto? No. El receptor debe rechazarlo, admitiendo solo la pequeña tolerancia de reloj definida por el perfil.
5. Audiencia equivocada
En un perfil que exige aud, un token fue emitido para api-a y llega a api-b. ¿Debe bastar con protección y exp válidos? No. api-b debe verificar que figura entre los destinatarios previstos.
6. Necesidad de secreto
Un sistema debe transportar un dato que ningún intermediario pueda leer. ¿Basta JWS? No. JWS protege integridad, no confidencialidad; el caso exige JWE o un diseño que cifre la información para el destinatario.
Método de respuesta
Clasifica primero el requisito: leer, detectar cambios, identificar un emisor confiable, limitar destinatario o mantener secreto. Después nombra el control: Base64URL no cubre ninguno de los dos últimos; firma no cifra; exp no reemplaza iss ni aud.
Para continuar el estudio del programa, consulta el Pack Temario TAI 2027, cuya ficha declara los 33 temas desarrollados, test y simulacro. Esta práctica no entrega ni usa tokens reales.
Preguntas frecuentes
¿Una firma JWT demuestra la identidad real de una persona?
No por sí sola. Un JWS puede usar firma o MAC; el receptor debe validar algoritmo permitido, clave confiada y los claims que exige su perfil.
¿exp sustituye la validación de iss y aud?
No. Cuando el perfil los exige, exp limita el tiempo de aceptación; iss identifica al emisor y aud limita los destinatarios previstos.
