Biscuit authorization

Original Article ↗ Hacker News Discussion ↗

Biscuit is a new authorization token format that aims to improve on JWTs and macaroons by supporting “attenuation” — the ability to derive more limited, short‑lived tokens offline while still being verifiable with public keys. Commenters explore how this enables capability-style access control, delegation, and per-request minimization, but note that revocation still requires stateful mechanisms and that Biscuit’s ecosystem and spec are less mature than established standards. Many see it as a promising option when you need rich, decentralized authorization logic, while simpler JWTs or session tokens remain preferable for straightforward, centralized auth scenarios.

Overview

  • Biscuit is presented as a capability-style authorization token with offline attenuation, public-key verification, and an embedded logic-based authorization language.
  • Several commenters find the concept “neat” and like the clarity of the docs, but note gaps around non-highlighted tradeoffs and missing “when not to use this” guidance.

Comparison with JWT, OAuth2, Macaroons

  • JWTs:
    • Strengths: simple transport of small claims, widely supported, easy to validate roles/permissions without DB calls.
    • Weaknesses: historical footguns (alg handling, “none” alg), complexity and large surface area vs. simple encrypted session cookies.
    • Biscuit aims to avoid JWT pitfalls via stricter spec and test suite, but tokens can be larger and slower to verify (one signature per block).
  • OAuth2:
    • Standard delegation is centralized and online; cannot do true offline attenuation/minimization.
    • Biscuit can integrate with OAuth/OIDC as an access-token format.
  • Macaroons:
    • Conceptually similar (attenuation, caveats), but macaroons are abstract, symmetric-key based and perceived as harder to implement and use.
    • Biscuit adds concrete encoding (protobuf), a logic language, and public-key verification.

Attenuation & Delegation

  • Offline attenuation is widely seen as Biscuit’s main differentiator:
    • Starting from a powerful token, holders can derive more restricted tokens (less scope, shorter lifetime, etc.) without contacting an IdP.
    • Viewed as particularly useful for per-request minimization and delegation in microservices.

Revocation & Statelessness

  • Biscuit uses per-block revocation IDs; revoking a block revokes that token and all derived ones.
  • Actual revocation still requires state (revocation lists, caches), same fundamental issue as JWTs.
  • Multiple commenters emphasize that “fully stateless revocation” is impossible; at best, you centralize and minimize the needed state.

Authorization Language & Policy DSL

  • Biscuit’s Datalog-like language carries both facts and checks inside tokens and at verifiers.
  • Some confusion around check if vs allow if / deny if, indicating a learning curve.
  • A few see this as a promising “policy DSL” approach for describing who/what/when/where/why, but also note the risk of overcomplexity.

Ecosystem, Maturity, and Implementations

  • Implementations exist in multiple languages, often via Rust or WASM bindings; some libraries lag behind.
  • There is a compliance test suite, but spec sections are still marked TODO and edge cases are evolving.
  • Concerns include inconsistent behavior across libraries, user-defined runtime limits, and lack of fuzz/property testing.
  • Consensus: strong potential, but the ecosystem is still maturing.