1. Pregunta y contexto
Múltiples servidores de recursos API aceptan tokens de acceso emitidos por un servidor de autorización. Necesitan saber si un token está activo, a qué cliente pertenece, qué scopes tiene y cuándo expira. El equipo de seguridad también requiere una revocación rápida para tokens robados. El diseño debe equilibrar la revocación en tiempo real, la baja latencia y la disponibilidad del servicio de autorización.
2. Qué está evaluando el entrevistador
- Si comprendes la semántica de introspección de la RFC 7662 y de revocación de la RFC 7009.
- Si las cachés, los eventos de revocación y las versiones evitan que resultados activos obsoletos oculten una revocación.
- Si distingues entre tokens opacos, validación local de JWT y pruebas de posesión como DPoP.
- Si las políticas de interrupción, reintentos, aislamiento de inquilinos y auditoría son explícitas.
3. Preguntas aclaratorias antes de responder
- ¿Los tokens son tokens de acceso de corta duración, refresh tokens o ambos?
- ¿Se revoca un solo token, una concesión (grant), una sesión de usuario o un cliente completo?
- ¿Cuánto retraso en la propagación de la revocación pueden aceptar los servidores de recursos?
- ¿Es necesario vincular una clave de cliente o una clave pública DPoP para evitar la reproducción de bearer tokens copiados?
4. Estructura de respuesta en 30 segundos
Utiliza endpoint, fuente de la verdad, caché, propagación de revocación y política de fallos.
El servidor de autorización expone endpoints protegidos de introspección y revocación. El almacén de estado conserva el hash del token, el cliente, los scopes, la expiración y la versión de revocación. Los servidores de recursos almacenan en caché los resultados activos durante un TTL corto y se suscriben a eventos de revocación para eliminar entradas de inmediato. Los scopes de alto riesgo fallan cerrados (fail closed) durante una caída de la autorización; las solicitudes de bajo riesgo pueden utilizar brevemente una caché positiva no expirada. Las consultas, revocaciones y fallos se auditan.
5. Análisis detallado paso a paso
Paso 1: Definir el estado del token y la autorización del endpoint
Solo los servidores de recursos de confianza pueden invocar la introspección. Devuelve los campos necesarios como active, client_id, username, scope, exp, iat y sub sin exponer datos de identidad innecesarios. El endpoint de revocación autentica a su emisor y el tipo de token, sigue la RFC 7009 para revocaciones repetidas y no revela si un token ya inválido existía previamente.
Paso 2: Diseñar el almacenamiento de estado y los índices
Usa una huella digital o hash del token como clave. Almacena la hora de emisión, expiración, ID de concesión, cliente, scopes, versión del estado y motivo de revocación. Indexa el ID de concesión para revocaciones masivas; mantén el texto plano confidencial fuera de los registros. Realiza sharding por inquilino o hash para que un solo cliente no se convierta en una partición caliente.
Paso 3: Manejar la caché y la propagación de la revocación
Almacena en caché los resultados positivos durante un TTL corto; evita cachés negativas prolongadas. Tras la revocación, publica la huella digital del token y la versión del estado. Los servidores de recursos eliminan las entradas locales de inmediato; las extracciones periódicas o verificaciones de versión reparan los eventos perdidos. Fuerza la introspección en línea para acciones de alto riesgo cuando la revocación en tiempo real justifique la latencia.
Paso 4: Manejar fallos, reintentos y prueba de posesión
Utiliza retroceso exponencial (exponential backoff) y circuit breaking en los tiempos de espera de introspección para que los servidores de recursos no sobrecarguen el servicio de autorización. Durante una caída, elige fail-closed o el uso breve de una caché positiva no expirada según el riesgo del scope. Con DPoP, verifica también la prueba de solicitud contra la clave pública vinculada al token, reduciendo el riesgo de reproducción de bearer tokens copiados.
6. Ejemplo de respuesta de alta calidad
Dividiría el sistema en endpoints de autorización, introspección, revocación, un almacén de estado, un bus de eventos de revocación y un SDK para el servidor de recursos. El almacén de estado se indexa mediante el hash del token y mantiene cliente, scopes, horas de emisión y expiración, ID de concesión, estado de revocación y versión. La introspección devuelve únicamente los campos que un servidor de recursos necesita y requiere autenticación del llamador.
>
El SDK almacena en caché scopes ordinarios durante treinta segundos e introspecciona scopes de alto riesgo en línea. La revocación admite revocar un solo token o toda la concesión, y luego publica un evento versionado. El SDK elimina su caché al recibirlo, mientras que un proceso de reparación periódico se encarga de los eventos perdidos. Una entrada de caché positiva cuya versión ya no coincida debe volver a introspeccionarse antes de su uso.
>
En caso de tiempo de espera en la autorización, las solicitudes de bajo riesgo pueden usar una caché positiva no expirada mientras que las de alto riesgo se rechazan. El circuit breaking y los reintentos con variación aleatoria (jitter) evitan una cascada de fallos. Con DPoP, el SDK verifica la prueba de solicitud y la clave vinculada. Las consultas, revocaciones, aciertos de caché y fallos se envían a un almacenamiento de auditoría con datos censurados para poder rastrear la propagación de un token robado.
7. Modos de fallo comunes
- Tratar la validación local de firmas JWT como si fuera una revocación en tiempo real.
- Almacenar en caché resultados activos durante mucho tiempo sin eventos de revocación ni comprobaciones de versión.
- Exponer la introspección públicamente o devolver campos de usuario innecesarios.
- Aplicar fail-open a todas las solicitudes durante una caída de la autorización.
- Reintentar sin tiempos de espera, circuit breaking o jitter, provocando una estampida de autenticación.
8. Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Por qué las cachés negativas deberían ser generalmente más cortas?
Es posible que un token se acabe de emitir, que una réplica esté desactualizada o que la revocación aún se esté propagando. Una caché negativa corta evita convertir una ausencia temporal en una ventana prolongada de invalidez.
Pregunta de seguimiento 2: ¿La revocación de un refresh token debería revocar también los tokens de acceso?
Depende de la política de concesión y de seguridad. Si se roba un refresh token, normalmente se revocan los tokens restantes bajo esa concesión y se permite que los servidores de recursos invaliden sus cachés mediante versiones o eventos.
Pregunta de seguimiento 3: ¿Cómo se evitan eventos de revocación duplicados o desordenados?
Incluye una versión monótona o marca de tiempo de revocación. Los consumidores aceptan solo una versión que sea al menos tan reciente como el estado local; los eventos duplicados siguen siendo idempotentes y un evento antiguo no puede restaurar un estado activo.