That said, the documentation does this thing I see a lot where the author focuses entirely on things that are good. It repeats and clarifies things that are good (you can reduce the scopes of offline, but never increase the scope of tokens, and you can do it offline, without contacting servers. Any server can validate credentials because it uses public keys. And did we tell you about attenuating tokens?), but it kind of sweeps anything that is NOT a discriminator under a rug a bit. I don't think it's malicious. Creators get excited about the exciting bits of their project.
But there are a lot of details that may or may not be present, and if I'm evaluating your thing, I want to know which exist an which don't. Given a long-term token, can I create short-term, auto-expiring tokens? Is there some revocation mechanism? How do these things line up against JWT or OAuth? When should I prefer this, but also when should I NOT prefer this?
Still, I like a lot about the documentation. I love how it's not afraid to get into the weeds about EXACTLY what it does without losing the clarity. It's really easy to follow when it gets technical, which is rare.
In a token, each block has a revocation id, so if you revoke a token, all the tokens derived from that one will be revoked as well. As for how to handle those revocation ids, it's the same strategies as in other systems, reintroducing some state to check revocation lists: https://www.biscuitsec.org/docs/guides/revocation/
> How do these things line up against JWT or OAuth? When should I prefer this, but also when should I NOT prefer this?
JWT has a lot of footguns, especially in the way it handles the list of algorithms, and libraries tend to all go through the same set of mistakes (a lot of them are stable now though). JWT are good to transmit a small amount of data, and are overall well supported. JWTs do not enforce any authorization system, you have to add one yourself.
Biscuit is very strict in how it deserializes and verifies tokens, so it avoids the usual JWT issues (partly by its spec, partly by an extensive test suite). Biscuits can be larger than JWTs, and can take longer to verify (one signature verification per block). Biscuit comes with its own authorization, based on a logic language, that can be both carried by the token and provided by the verifier. It has implementations in a lot of languages but is not as widely supported as JWT yet.
That said, the documentation does this thing I see a lot where the author focuses entirely on things that are good. It repeats and clarifies things that are good (you can reduce the scopes of offline, but never increase the scope of tokens, and you can do it offline, without contacting servers. Any server can validate credentials because it uses public keys. And did we tell you about attenuating tokens?), but it kind of sweeps anything that is NOT a discriminator under a rug a bit. I don't think it's malicious. Creators get excited about the exciting bits of their project.
But there are a lot of details that may or may not be present, and if I'm evaluating your thing, I want to know which exist an which don't. Given a long-term token, can I create short-term, auto-expiring tokens? Is there some revocation mechanism? How do these things line up against JWT or OAuth? When should I prefer this, but also when should I NOT prefer this?
Still, I like a lot about the documentation. I love how it's not afraid to get into the weeds about EXACTLY what it does without losing the clarity. It's really easy to follow when it gets technical, which is rare.