Refresh Token Coalescing es un patrón de diseño en sistemas de autenticación y autorización que aborda el problema de múltiples solicitudes concurrentes para la renovación de tokens de acceso utilizando el mismo refresh token. Cuando un cliente (por ejemplo, una aplicación frontend o un microservicio) realiza varias llamadas a APIs protegidas y sus tokens de acceso expiran casi simultáneamente, podría intentar renovarlos varias veces. Esta técnica asegura que, para un refresh token dado, solo una solicitud de renovación sea procesada por el servidor de autorización, mientras que las solicitudes subsiguientes (dentro de una ventana de tiempo corta) esperan el resultado de la primera y reutilizan el nuevo par de tokens (access y refresh) generado. Esto previene el consumo excesivo de recursos del servidor, la invalidación prematura de refresh tokens y posibles condiciones de carrera.
Esta técnica es comúnmente implementada en Identity Providers (IdPs) y servicios de autenticación que manejan un alto volumen de tráfico y requieren robustez. Plataformas como Auth0, Okta o AWS Cognito pueden incorporar lógicas de coalescing internamente para optimizar sus operaciones de renovación de tokens. En el lado del cliente, bibliotecas y SDKs de autenticación para frameworks como React, Angular o Vue.js, o para microservicios, pueden implementar un mecanismo de 'request queueing' o 'memoization' para emular este comportamiento, asegurando que solo una solicitud de renovación esté 'en vuelo' por cada refresh token activo. Por ejemplo, un SDK podría mantener un mapa de refresh tokens en proceso y devolver la misma promesa a todas las solicitudes concurrentes para el mismo token.
Para un Arquitecto de Sistemas, Refresh Token Coalescing es crucial por varias razones. Estratégicamente, mejora la resiliencia y escalabilidad del sistema de autenticación al reducir la carga en el IdP y la base de datos de tokens, evitando el 'thundering herd problem' en la renovación. Desde una perspectiva de seguridad, mitiga el riesgo de 'replay attacks' y la invalidación accidental de refresh tokens, lo que podría llevar a la desautenticación masiva de usuarios. El trade-off principal es la complejidad de implementación, tanto en el servidor de autorización (gestionando el estado de las solicitudes de renovación) como en el cliente (coordinando las solicitudes). Una implementación defectuosa podría introducir latencia o, peor aún, interbloqueos. La decisión de implementarlo debe sopesar el volumen de tráfico esperado, la criticidad de la disponibilidad del sistema y la tolerancia a la complejidad operativa, siendo casi indispensable en sistemas distribuidos de gran escala.