Los tokens de acceso deben actualizarse con frecuencia en general.
Con las sesiones tradicionales, cada vez que un usuario realiza una solicitud a su aplicación y envía su Id. de sesión a través de una cookie o encabezado http, usted verifica la sesión si aún es válida (obtenga la sesión por su ID desde la base de datos o la memoria y verifique si la columna "activa" es "verdadera"). Además, puede invalidar la sesión en su servidor cada vez que lo desee (establezca la columna "activa" de esta sesión en particular en "falso"). Por ejemplo, cuando la cuenta de los usuarios se ve comprometida, puede invalidar todas las sesiones activas asociadas a este usuario específico.
Con los tokens de acceso, esto no se puede hacer de esta manera, porque no tiene una sesión en el servidor. El servidor solo obtiene el token de acceso, comprueba su firma y la fecha de caducidad, y eso es todo. Supongamos que su token de acceso tiene un tiempo de caducidad de 24 horas. Cuando un usuario activo se ve comprometido, no puede invalidar sus "sesiones", porque no hay ninguna. Hay solo un montón de tokens de acceso en la naturaleza que se emitieron para este usuario (en un momento en que la cuenta de los usuarios aún no estaba comprometida). Por lo tanto, tiene una aplicación con un usuario comprometido y una cantidad de tokens de acceso válidos asociados con este usuario en particular que son válidos para las próximas 24 horas. ¡Buena suerte! Tengo curiosidad por saber hasta dónde llega el hacker en estas 24 horas.
Entonces, lo que normalmente quieres hacer es actualizar el token con frecuencia. Cómo implementar esto en detalle depende en gran medida de su caso de uso y no puede ser respondido de manera general. Tal vez pueda revisar el protocolo OAuth2 que introduce el token de actualización. En resumen, un token de actualización puede emitir un nuevo token de acceso para un usuario específico. De esa manera, puede lograr cortos tiempos de caducidad para su token de acceso sin molestar al usuario con un proceso de autenticación.
Para su caso específico, diría que no puede manejar el "evento" cuando un usuario ha cambiado su contraseña. Un usuario emite un token de acceso: en este momento, el token se crea y es válido hasta que llega la hora de caducidad. Lo que pase hasta este momento no importa.