invalid_grant por reloj desincronizado: el error que se lee como fallo de credenciales

Un desarrollador ha documentado cómo un error invalid_grant en una integración con Google Search Console resultó ser causado no por una clave rota o un servicio deshabilitado, sino por un reloj del sistema operativo desincronizado tres días. El incidente sirve como recordatorio de que los tokens de vida corta son sensibles a la hora, no solo a las credenciales.

La trampa del error genérico

El sistema de monitoring enviaba un digest diario. Uno de los módulos, que consultaba Search Console usando una cuenta de servicio (service account) y un JWT, devolvía un error HTTP 400 con el código invalid_grant. La descripción del error indicaba claramente: "Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your iat and exp values".

Al haber estado lidiando recientemente con una cuenta comprometida, el instinto fue revisar si la clave se había rotado o si el acceso al proyecto se había revocado. Sin embargo, el resto de las comprobaciones del mismo script (pings a API externas, validación de sitemaps) funcionaban correctamente. La clave estaba en la línea de título del informe, que mostraba una fecha tres días anterior a la real. Al comprobar la hora del servidor con un simple curl a un endpoint de Google, la discrepancia quedó confirmada.

El problema técnico es directo: el script generaba el JWT usando time() del sistema. Si el reloj dice que son las 10:00 del día 17, laclaim iat (issued at) será esa fecha y exp (expiration) será 60 minutos después. Cuando Google recibe un token que afirma haberse emitido hace tres días y haber expirado hace dos días, lo rechaza. El error invalid_grant cubre tanto credenciales incorrectas como problemas de tiempo, lo que lleva a muchos a buscar primero en las claves y no en el NTP del host.

Diagnóstico rápido

Antes de rotar claves o auditar permisos de IAM, el consejo es comparar la hora local del servidor que firma el token con un reloj de referencia. Un curl -I a un dominio confiable y leer el header Date es suficiente. Si hay discrepancia, el problema es de sincronización de reloj, no de seguridad.

También ayuda decodificar el JWT enviado en un visor externo para ver los valores numéricos de iat y exp y convertirlos a fecha legible. Si la diferencia con la fecha actual es de días, el caso está cerrado. Este tipo de fallos es más común de lo que se cree en entornos de CI/CD o en instancias de nube recién provisionadas donde el servicio NTP puede tardar en arrancar o no estar configurado por defecto.

La lección operativa no es solo técnica, sino de diseño de errores: el mensaje de Google era preciso, pero el error genérico invalid_grant actúa como un embudo que oculta la causa raíz si no se lee el campo error_description con atención. Para quien administra infraestructura, mantener la sincronización de tiempo es una tarea de higiene básica, pero su impacto en la seguridad está a menudo invisibilizado por la complejidad de los protocolos de autenticación moderna.