Verificación incorrecta, lo que no se comprueba

Un validador correcto hace, en orden, cuatro cosas: comprueba que el algoritmo declarado está en su lista; verifica la firma con una clave que ya conocía; comprueba las afirmaciones que le atañen (el emisor iss, la audiencia aud); y comprueba la vigencia (exp, y nbf si lo hay). Si falta alguna, el token se puede aceptar siendo falso, ajeno o caducado.

Decodificar es solo leer los campos del token: cualquier biblioteca lo hace sin clave y sin esfuerzo. Que el validador haya leído el sub y el exp del token no dice nada de si el token es auténtico. Abre envios.val, el validador completo, y úsalo como patrón de lo que debe aparecer.

En los validadores, cada línea exigir es una condición; si se cumplen todas, el token se acepta. Para saber qué hace de verdad un validador no sirve fiarse de su nombre ni de la intención del equipo: hay que leer qué exige. Los comentarios que dicen «pendiente» o «mejora» indican cosas que el código no hace todavía.

Revisa los cinco archivos .val y localiza el que toma los datos del token sin llegar a comprobar su firma.

La caducidad es lo que acota el daño de un token filtrado: pasado exp, ya no sirve. Un validador que la omite convierte cualquier token en eterno, aunque el emisor lo haya hecho de corta vida. Algunas veces la omisión se justifica «para pruebas» y se queda en producción, y por eso el comentario del equipo no es una razón sino un hallazgo.

Revisa los validadores y localiza el que verifica la firma, el emisor y la audiencia, pero nunca mira la caducidad.

Cuando un mismo emisor firma tokens para varias APIs, la firma es válida en todas. Solo el claim aud dice para cuál se emitió cada uno. Si una API no lo comprueba, un token emitido para un servicio de poco riesgo (digamos, uno que solo lee) se puede presentar en otro más sensible. Es el equivalente de usar una llave de la oficina para abrir el almacén porque ambas las hizo el mismo cerrajero.

Localiza el validador que verifica firma, emisor y caducidad, pero no la audiencia.

Algunas cabeceras traen campos como jku o jwk, que apuntan a un conjunto de claves o lo incluyen. Son legítimos para quien emite, pero un verificador no debe usarlos para decidir en qué clave confiar: si el token trae la clave con la que se va a comprobar, cualquiera puede producir un token y adjuntar su propia clave. Es el mismo error de la sala de verificación de firmas del módulo de asimétrico, con otra forma: la clave de confianza la pone quien verifica, no el mensaje.

Abre portal.val y fíjate de dónde saca la clave.