Revocar un token sin tener que derribar la sesión entera
BinCat es un SDK de Python para emitir, validar y revocar tokens Fernet y JWT con registro de auditoría, con un panel encima para hacerlo sin escribir código. La pregunta que lo motivó: por qué revocar un acceso obligaba tantas veces a cerrar la sesión completa.
- python
- criptografia
- jwt
- seguridad
- tokens
- sdk
Una petición 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 válido hasta que caduca por su cuenta, o hay que invalidar la sesión entera. BinCat nació de resolver justo eso: emitir, validar y revocar tokens de forma individual, con registro de cada operación.
Dos tipos de token, cada uno para su caso
Fernet, de la librería cryptography, para cifrado simétrico cuando el mismo sistema emite y valida. JWT firmados criptográficamente con claims con estado, para cuando el token viaja entre servicios distintos. Los intervalos de expiración se configuran desde la API o desde el panel, y cualquier token individual se puede revocar al instante sin tocar los demás, que es la diferencia frente a depender solo de la expiración natural.
Qué trae el paquete
- Un SDK de Python que se integra directamente en una aplicación existente.
- Un panel de una sola página, tema oscuro, con recuento de tokens totales, activos, revocados y expirados, y una consola de logs que traza la actividad según ocurre.
- Una API REST con seis endpoints: generar, validar, revocar, purgar y consultar el log de las últimas cincuenta operaciones.
- Registro en SQLite de cada emisión, validación y revocación, para poder responder después quién tenía acceso y cuándo dejó de tenerlo.
La clave de cifrado no se toca a mano
Si BinCat no encuentra una clave en .env al arrancar, genera una criptográficamente segura por su cuenta. Es la misma lógica 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 rotación mágica que salve ese paso: hay que reemitir.
Los tests corren contra una base de datos SQLite aislada, así que nunca tocan la de desarrollo ni arrastran estado entre ejecuciones.
