Cuando verification empieza a fallar justo alrededor de un cambio de signing key, lo trato como key lifecycle problem, no solo como invalid signature. El token puede estar bien y el verifier también; el fallo puede estar en overlap old/new, selección por kid o cache de JWKS.
Mi pregunta central es:
¿El token está firmado con una key que el verifier todavía puede encontrar y confiar durante el lifetime restante del token?
Empiezo con JWKS Validator si tengo token y current key set.
Paso 1: leo kid, issuer y expiration
{
"alg": "RS256",
"kid": "signing-key-2026-09"
}
{
"iss": "https://login.example.com/",
"exp": 1789203600
}
Necesito saber quién debería poseer la key, qué kid selecciona el token y cuánto tiempo debería seguir verificando.
Paso 2: comparo kid con current JWKS
Durante una rotación normal puedo esperar old/new public keys simultáneamente:
{
"keys": [
{ "kid": "signing-key-2026-06", "kty": "RSA", "alg": "RS256", "use": "sig" },
{ "kid": "signing-key-2026-09", "kty": "RSA", "alg": "RS256", "use": "sig" }
]
}
Si un token old aún no expiró pero su key desapareció, reviso si se eliminó demasiado pronto o estoy mirando wrong issuer/environment.
Paso 3: planned rollover no es emergency revocation
En planned rotation suelo mantener old verification key el tiempo necesario para tokens ya emitidos.
En emergency rotation por compromise, mantener old key confiable puede ser lo incorrecto. Tokens aún no expirados pueden tener que invalidarse inmediatamente.
Por eso no creo una regla universal “old key siempre hasta el último exp”.
Paso 4: inspecciono cache de JWKS
Busco:
- cache TTL;
- refresh controlado ante unknown
kid; - caches en gateway/framework;
- instances con estados diferentes;
- CDN/proxy stale;
- errores que dejan old JWKS fijado indefinidamente.
Un kid miss puede justificar refresh desde la trusted JWKS location, no desde una URL elegida por el token.
Paso 5: confirmo que new key pertenece al issuer correcto
expected issuer
↓
trusted metadata/config
↓
trusted JWKS
↓
matching kid
↓
compatible JWK
↓
signature verification
No considero una rotation correcta si production token se verifica con un staging key set accidental.
La guía de issuer validation cubre esa relación.
Paso 6: reviso key metadata
Aunque kid coincida, reviso kty, alg, use y key_ops cuando existen. El token algorithm y key type deben ser compatibles.
Además, allowed algorithms vienen de application config.
Paso 7: comparo timing de rotation y token lifetime
11:59 token firmado con old key
12:00 new signing key activo
12:01 old public key eliminado
12:30 old token todavía tiene 29 minutos de vida
En planned rollover eso crea un verification gap.
El overlap debe considerar maximum token lifetime, cache y buffer operativo. No es un número fijo definido por JWT.
Paso 8: reproduzco con old y new token
Comparo un token inmediatamente anterior y otro posterior a rotation contra current trusted JWKS.
Así separo missing old key, missing new key, stale cache, wrong issuer y un signature problem independiente.
Si aparece kid not found, uso la guía de JWT kid.
No desactivo verification para salvar el rollout
Si new key aún no llegó, arreglo publication/cache/distribution. No convierto temporalmente la API en un sistema que acepte claims sin firma.
Mi secuencia saludable para planned rotation
1. Publicar new public key en trusted JWKS
2. Mantener old public key
3. Empezar a firmar con new private key / kid
4. Verifiers aceptan old y new
5. Esperar fin de old-token acceptance window
6. Retirar old public key cuando policy lo permita
Mi checklist de key rotation
- Leo
iss,alg,kid,exp. - Confirmo expected issuer.
- Inspecciono current trusted JWKS.
- Busco token
kid. - Reviso
kty,alg,use,key_ops. - Verifico con JWKS Validator.
- Reviso cache age y refresh.
- Comparo token lifetime con old-key availability.
- Distingo rollover de emergency revocation.
- Mantengo signature verification activa.
JWT key rotation es coordinar token lifetime, publicación de public keys, key selection, cache refresh e issuer trust, no solo cambiar una private key.
