biscuit-based identity and authorization

I’m working on https://www.hessra.net/, an identity + authorization service built around [Biscuits](https://www.biscuitsec.org/) instead of JWTs. The goal is to decompose auth primitives so they’re easier to use in service-to-service cases, while also showing off what Biscuit tokens make possible.

JWTs feel like problems waiting to happen. I think biscuits give stronger guarantees and are harder to get wrong.

One piece I’ve shipped is an identity token that can be delegated offline. For example, “company:alice” can delegate to “company:alice:agent,” and that token can then be used to request an authorization token. This makes for a neat API key model: you can issue a simple opaque identity token to your customer (e.g. “customer123”) without having to maintain a DB of hashes/expirations, since those are encoded into the token. Later, you can upgrade security by exchanging the identity token for an authorization token, or let customers delegate access (e.g. “customer123:marketing”).

I’ve also been experimenting with higher-order authorization flows:

• Service chains: each step in a request’s path (edge → app → DB) can add attestations, so later services can validate the full chain.

• Multi-party authorization: requiring two independent services/orgs to co-sign an authorization token, useful for cross-org or on-prem deployments.

Right now I’m building an OAuth 2.1 profile where the identity token replaces a refresh token and the authorization token stands in for the access token. I’m especially interested in hearing where people find OAuth clunky in practice, or stories from folks who’ve built auth systems with other token types (macaroons, biscuits, etc.) or for use cases where OAuth didn’t fit well.

▲

AceJohnny2 3 days ago | parent [-]

Are Eclipse Biscuits related to Google Macaroons? https://research.google/pubs/macaroons-cookies-with-contextu...

(what a word salad that is...)

	▲	ymyms 3 days ago \| parent [-]
		Biscuits are in the same family as macaroons in that they are bearer tokens that can be attenuated offline, but they go further. A biscuit carries a chain of signed “blocks” that can contain facts, rules, and checks in a small Datalog-like logic language. That lets the token itself express richer authorization context, not just restrictions. Key differences from macaroons: - Crypto model: Macaroons use HMAC, so every verifier needs the shared secret. Biscuits use public/private keypairs so any verifier with the public key can check validity. - Expressiveness: Macaroons only add caveats (restrictions). Biscuits can encode facts, rules, and checks, enabling more complex policies to travel with the token. so you can attest and attenuate (and do some other tricky stuff if you want) - Delegation: Both support attenuation, but biscuits do it with signed blocks that are verifiable and can be chained across services. So conceptually similar, but biscuits aim to be more decentralized and policy-rich.