La rotación ayuda a detectar replay, pero convierte el refresh token en estado compartido y reemplazable. En un Worker serverless, solicitudes simultáneas pueden ejecutarse en isolates distintos sin memoria común. Si dos jobs renuevan la misma autorización, uno puede invalidar el token que aún espera el otro. La solución requiere coordinación y almacenamiento duradero, no solo reintentar la llamada al endpoint.
Guarda un registro por usuario o cuenta conectada: refresh token cifrado, vencimiento del access token, permisos concedidos, proveedor, versión del token, estado de renovación y último éxito. No lo asocies a una instancia efímera del Worker. Protege las claves por separado y nunca escribas tokens en logs.
Usa lock, lease o single-flight por autorización. La segunda solicitud debe esperar y volver a leer el registro, usando el access token nuevo en lugar de presentar otra vez el anterior. Añade control de versión para impedir que una respuesta lenta sobrescriba la generación más reciente.
El servidor OAuth y tu base normalmente no comparten una transacción. El proveedor puede invalidar el token previo y la respuesta perderse antes de persistir el reemplazo. Repetir el token antiguo puede parecer replay y revocar toda la familia activa.
| Resultado | Respuesta segura | Evita |
|---|---|---|
| Renovación y escritura confirmadas | Compartir la versión nueva | Devolver un token viejo en caché |
| Otro Worker ya renovó | Volver a leer la versión ganadora | Reutilizar el token anterior |
| Timeout sin conocer el resultado | Marcar como incierto y seguir la política del proveedor | Reintentos ilimitados del token viejo |
| Invalid grant o señal de replay | Detener, revocar sesión local y pedir autorización de nuevo | Repetir en bucle o restaurar en silencio |
Algunos proveedores documentan tolerancia, idempotencia o recuperación; otros no. Implementa su contrato, limita el timeout y representa explícitamente el resultado incierto. No inventes una política universal para un intercambio irreversible de credenciales.
Los Workers sin estado no ofrecen exclusión entre isolates mediante memoria del proceso. Usa almacenamiento transaccional o un coordinador por autorización. Durable Objects aportan coordinación y estado persistente consistente, pero pueden procesar solicitudes fuera del orden de llegada; conserva transiciones y versiones explícitas. Una base relacional con compare-and-swap o bloqueo también puede servir según el runtime.
Cifra los refresh tokens, limita permisos y vincula cada registro al usuario o tenant correcto. Protege callback y renovación y trata la sesión del navegador aparte. RFC 9700 recomienda rotación o tokens vinculados al emisor para clientes públicos. La reutilización puede señalar un compromiso, así que trátala como evento de seguridad.
Simula dos renovaciones simultáneas, reinicio antes de persistir, timeout tras aceptar el proveedor, error de base y detección de replay. Comprueba que solo hay un intercambio, sobrevive el token más reciente y no se filtran secretos en logs. Prueba también logout y revocación remota.
La rotación convierte el almacenamiento de refresh tokens en un problema de concurrencia. Coordina una renovación por autorización, persiste con control de versión, diferencia fallo conocido de resultado incierto y toma en serio el replay. Un runtime stateless necesita coordinación stateful cuando usar el token invalida su versión anterior.