Renovar y cerrar la sesión: lo que el servidor debe invalidar

Un token de renovación que no cambia es una llave maestra con fecha lejana. La guía de seguridad de OAuth (RFC 9700) pide, para clientes públicos como una app, una de dos defensas: tokens de renovación atados al cliente (de modo que no sirvan desde otro aparato) o rotación: cada renovación entrega un token nuevo e invalida el anterior. Con rotación, un token viejo que reaparece es una señal: o la app lo repitió por un fallo, o alguien tiene una copia. Lo prudente es invalidar la cadena entera y pedir un inicio de sesión nuevo.

La rotación solo funciona si el servidor la hace cumplir: que un token se presente dos veces y las dos se acepten es precisamente lo que debía impedir.

El registro de renovaciones del servidor anota, por evento, el dispositivo, el origen, el token presentado y el que se entregó a cambio. En una cadena sana, cada token presentado aparece una vez y el siguiente evento presenta el que se entregó. Cuando un mismo token aparece en dos eventos, y más si vienen de dispositivos distintos, hay dos portadores del mismo valor.

Abre renovaciones.txt. La respuesta es el token, no el evento; el evento y el dispositivo son los datos que citarás para que el equipo de la API lo localice.

Cerrar sesión en la app borra lo guardado en el aparato. Eso no invalida nada en el servidor. La prueba es medir cuánto tiempo siguió aceptando el servidor una copia anotada antes del cierre, en una sesión propia del equipo de pruebas: cuanto más tiempo, más margen tiene quien se hubiera hecho con ella.

Lee cierre-de-sesion.txt. Cuenta los minutos desde el cierre hasta la última petición que el servidor aceptó con la copia.

La política de Nogalera dice qué debe pasar al cerrar sesión: la app llama a una operación del servidor y borra lo guardado. La traza del cierre anota las llamadas al servidor que la app hizo en ese momento. Contrastar las dos cosas da el hallazgo: lo prometido y lo observado no coinciden.

Un buen hallazgo cita la política y la traza, no una opinión. Lee ambos archivos y busca la operación.

La revocación de tokens tiene su propio estándar (RFC 7009): un punto del servidor de acceso donde el cliente avisa «este token ya no debe valer». Un cierre de sesión completo hace las dos cosas: borra lo local, para que la app no vuelva a usarlo, y revoca en el servidor, para que, aunque exista una copia, deje de valer. Con solo lo primero queda una ventana, y se mide como en la tarea 3; con solo lo segundo la app conserva basura sensible en el aparato.

El token de acceso de vida corta no se revoca cada vez en muchos diseños; por eso su vida corta importa, y por eso la política limita ese tope.