Autorización Biscuit

Artículo original ↗ Discusión en Hacker News ↗

Biscuit es un nuevo formato de token de autorización que busca mejorar JWTs y macaroons al soportar la “atenuación”: la capacidad de derivar tokens más limitados y de vida corta fuera de línea, manteniéndose verificables con claves públicas. Los comentaristas exploran cómo esto permite control de acceso de estilo capability, delegación y minimización por solicitud, pero señalan que la revocación todavía requiere mecanismos con estado y que el ecosistema y la especificación de Biscuit son menos maduros que los estándares establecidos. Muchos lo ven como una opción prometedora cuando necesitas lógica de autorización rica y descentralizada, mientras que JWTs o tokens de sesión más simples siguen siendo preferibles para escenarios de autenticación centralizados y sencillos.

Resumen general

  • Biscuit se presenta como un token de autorización de estilo capability, con atenuación fuera de línea, verificación con clave pública y un lenguaje de autorización basado en lógica integrado.
  • Varios comentaristas encuentran el concepto “interesante” y les gusta la claridad de la documentación, pero señalan lagunas en torno a los compromisos no destacados y la falta de orientación sobre “cuándo no usar esto”.

Comparación con JWT, OAuth2, Macaroons

  • JWTs:
    • Fortalezas: transporte simple de pequeñas reclamaciones, ampliamente soportado, fácil de validar roles/permisos sin llamadas a la base de datos.
    • Debilidades: errores históricos (“footguns”) (manejo de alg, algoritmo “none”), complejidad y gran superficie en comparación con simples cookies de sesión cifradas.
    • Biscuit busca evitar los problemas de JWT mediante una especificación más estricta y una suite de pruebas, pero los tokens pueden ser más grandes y más lentos de verificar (una firma por bloque).
  • OAuth2:
    • La delegación estándar es centralizada y en línea; no puede hacer verdadera atenuación/minimización fuera de línea.
    • Biscuit puede integrarse con OAuth/OIDC como un formato de token de acceso.
  • Macaroons:
    • Conceptualmente similares (atenuación, caveats), pero los macaroons son abstractos, basados en clave simétrica y se perciben como más difíciles de implementar y usar.
    • Biscuit añade codificación concreta (protobuf), un lenguaje lógico y verificación con clave pública.

Atenuación y delegación

  • La atenuación fuera de línea es ampliamente vista como el principal diferenciador de Biscuit:
    • Partiendo de un token potente, los poseedores pueden derivar tokens más restringidos (menos alcance, vida útil más corta, etc.) sin contactar a un IdP.
    • Se considera especialmente útil para la minimización por solicitud y la delegación en microservicios.

Revocación y ausencia de estado

  • Biscuit usa identificadores de revocación por bloque; revocar un bloque revoca ese token y todos los derivados.
  • La revocación real sigue requiriendo estado (listas de revocación, cachés), el mismo problema fundamental que con JWTs.
  • Varios comentaristas enfatizan que la “revocación totalmente sin estado” es imposible; como mucho, centralizas y minimizas el estado necesario.

Lenguaje de autorización y DSL de políticas

  • El lenguaje tipo Datalog de Biscuit transporta tanto hechos como verificaciones dentro de los tokens y en los verificadores.
  • Hay cierta confusión entre check if y allow if / deny if, lo que indica una curva de aprendizaje.
  • Algunos ven esto como un enfoque prometedor de “DSL de políticas” para describir quién/qué/cuándo/dónde/por qué, pero también señalan el riesgo de sobrecomplicación.

Ecosistema, madurez e implementaciones

  • Existen implementaciones en varios lenguajes, a menudo mediante enlaces de Rust o WASM; algunas bibliotecas van retrasadas.
  • Hay una suite de pruebas de conformidad, pero las secciones de la especificación todavía están marcadas como TODO y los casos límite están evolucionando.
  • Las preocupaciones incluyen comportamiento inconsistente entre bibliotecas, límites de tiempo de ejecución definidos por el usuario y falta de pruebas de fuzz / property testing.
  • Consenso: gran potencial, pero el ecosistema todavía está madurando.