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.