Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
I ported biscuit-java to Kotlin for an internal project. In the course of doing so, I went from a naive superfan to a somewhat grizzled advocate. Here's my high level summary:
Why Biscuit instead of JWTs?
tl;dr, Biscuit (and Macaroons) can attenuate, JWTs can't.
Read: https://fly.io/blog/api-tokens-a-tedious-survey/
What does this mean? Let's say you're given a token to access System A and B whenever and however you want. You can create a new token from your token (attenuate) that only gives access to System A for the next 5 minutes.
Basically: attenuation gives a capability system.
Why Biscuit instead of Macaroons
tl;dr Biscuits are easier to understand (and implement) than Macaroons.
Watch: https://www.youtube.com/watch?v=MZFv62qz8R
Macaroons are clunky and hard to work with in practice. That's probably not a feature you want in your choice of token technology.
Biscuits contain simple facts and clear policies written in Datalog.
Why NOT Biscuits
Immaturity.
- AFAIK there is no compliance suite for all the Biscuit libraries linked https://www.biscuitsec.org/; and as such, unsurprisingly, there are corner case incompatibilities, especially in the authorization language parsers and Datalog expressions/operators.
- The Datalog runtime limits are user-defined. What is the maximum number of facts, application iterations, or even timeouts? That's up to you.
- Biscuit v2 (v3-4 in the proto) is the Official Latest Version. Some of the libraries support the older versions to varying degrees.. and the way that backwards compatibility is implemented gave me pause.
- Whole sections of the specification are `TODO`.
- The Datalog data types are bounded by the underlying protobuf definitions; and the libraries use the language native data types. There are casts and undefined behaviour at the extremes.
- Many of the libraries do little things like calling the equivalent of `Time.now()` internally. IMHO this sort thing should be stateless.
- There's heaps of tests, which is great! But, I didn't see any fuzz or property tests, which is less great.
Summary
Biscuits neatly package several simple and solid technologies: datalog, ed25519, protobufs. Once the ecosystem is mature, it'll be incredible.
(biscuit maintainer here)
thanks for the kind words!
as for the compliance suite, there is one: https://github.com/biscuit-auth/biscuit/tree/main/samples/cu... which has been instrumental when i implemented biscuit-haskell. It might not cover anything, but it is updated everytime a new corner-case is identified.
could you elaborate wrt backward compatibility? The current model is opt-in, so you only pay for the features you use (that allows incremental updates, with biscuit-rust and biscuit-haskell leading the pack).
I see two todos in the spec indeed, i'll have a go at filling them out (they are implied by the rest of the spec and are implemented consistently across the various libraries, so it's more of a "writing things down" issue. I do agree that the spec is not airtight as it is. The compliance suite is there for that as it disambiguates a lot of things.
Other points are about library specifics. I know biscuit-rust and biscuit-haskell very well, biscuit-java less so. It is a bit lagging since the company working on it has had trouble allocating time on it.
In any case, if you have issues with specific things in libraries, don't hesitate to ping maintainers or open issues to see what we can do. biscuit-rust and its derivatives are actively maintained. biscuit-haskell is rather stable (but lacks support for snapshots). biscuit-java and biscuit-go are in need of some love, but nothing undoable