Emisor, audiencia, caducidad y reloj

El RFC 7519 registra un puñado de afirmaciones con nombre fijo. Cuatro deciden si un token firmado debe aceptarse: iss (quién lo emitió), aud (para quién se emitió), exp (desde cuándo ya no vale) y nbf (antes de cuándo todavía no vale). La norma pide que, si un servicio no figura en la audiencia de un token, lo rechace; y las buenas prácticas del RFC 8725 añaden que, cuando un mismo emisor sirve a varios destinatarios, cada uno exija la audiencia y la compare.

La razón es sencilla: con un emisor compartido, todos los tokens se firman con la misma clave. Sin audiencia, un token que se le dio a un servicio poco sensible sirve igual en el más sensible.

La lista de emisores aceptados es una lista de confianza: cada entrada es alguien a quien el servicio le cree lo que diga de cualquier usuario. Un emisor de pruebas en esa lista equivale a darle a quien controle sus claves la capacidad de crear clientes en producción. Comprobar el emisor solo tiene sentido si además las claves que se cargan son las de ese emisor y de ningún otro.

Abre el laboratorio y compara validacion-pagos-api.yml con validacion-boletas-api.yml.

Los relojes de dos servidores nunca coinciden al segundo, y por eso la norma permite un pequeño margen al comparar exp y nbf, que en la práctica es de pocos minutos. El margen se suma a la vida del token: un margen grande convierte un token de pocas horas en uno de días, y vuelve inútil cualquier caducidad corta que se haya pensado. Si un equipo se desfasa mucho, el arreglo es sincronizar su reloj, no agrandar el margen de todos.

Revisa el valor del margen de pagos-api y el comentario que lo justifica.

Ahora cruza la configuración con los hechos. En tokens-recibidos.txt cada fila es un token que pagos-api aceptó; compara su emisor, su audiencia y su exp con la hora de recepción. Uno vino del emisor de pruebas, otro estaba vencido desde la noche anterior y otro se emitió para un servicio distinto.

Con lo que encontraste, toca escribir la recomendación para pagos-api. La app móvil seguirá enviando tokens y sus errores «aud inválido» de junio hay que resolverlos en su origen, no desactivando la comprobación.