Saltar al contenido
Volver al blog
2 min es

Revocar un token sin tener que derribar la sesion entera

BinCat es un SDK de Python para emitir, validar y revocar tokens Fernet y JWT con registro de auditoria, con un panel encima para hacerlo sin escribir codigo. La pregunta que lo motivo: por que revocar un acceso obligaba tantas veces a cerrar la sesion completa.

  • python
  • criptografia
  • jwt
  • seguridad
  • tokens
  • sdk
Revocar un token sin tener que derribar la sesion entera

Una peticion que he visto repetirse: revocar el acceso de un token concreto sin forzar a todo el mundo a volver a autenticarse. Muchas implementaciones caseras de tokens no dejan margen para eso: o el JWT es valido hasta que caduca por su cuenta, o hay que invalidar la sesion entera. BinCat nacio de resolver justo eso: emitir, validar y revocar tokens de forma individual, con registro de cada operacion.

Dos tipos de token, cada uno para su caso

Fernet, de la libreria cryptography, para cifrado simetrico cuando el mismo sistema emite y valida. JWT firmados criptograficamente con claims con estado, para cuando el token viaja entre servicios distintos. Los intervalos de expiracion se configuran desde la API o desde el panel, y cualquier token individual se puede revocar al instante sin tocar los demas, que es la diferencia frente a depender solo de la expiracion natural.

Que trae el paquete

  • Un SDK de Python que se integra directamente en una aplicacion existente.
  • Un panel de una sola pagina, tema oscuro, con recuento de tokens totales, activos, revocados y expirados, y una consola de logs que traza la actividad segun ocurre.
  • Una API REST con seis endpoints: generar, validar, revocar, purgar y consultar el log de las ultimas cincuenta operaciones.
  • Registro en SQLite de cada emision, validacion y revocacion, para poder responder despues quien tenia acceso y cuando dejo de tenerlo.

La clave de cifrado no se toca a mano

Si BinCat no encuentra una clave en .env al arrancar, genera una criptograficamente segura por su cuenta. Es la misma logica que aplico en Password Sentinel: cuanto menos dependa la seguridad de que alguien recuerde configurar algo bien, menos formas hay de que se quede mal configurado. Si una clave se filtra, el procedimiento es simple: borrar .env, dejar que se genere una nueva, y reemitir los tokens que estaban cifrados con la anterior. No hay rotacion magica que salve ese paso: hay que reemitir.

Los tests corren contra una base de datos SQLite aislada, asi que nunca tocan la de desarrollo ni arrastran estado entre ejecuciones.