Open divarvel opened 1 year ago
I haven't touched this crate in a while, and I'd definitely consider it still under "experimental" status. But I have some free time starting around this Monday, so I could see about revamping it in a few days to work with the latest Biscuit API.
I would also welcome ideas on how to best integrate biscuit-auth
as middleware. I'm happy to have that conversation here or in the Matrix channel; whichever is easier.
If I recall correctly, I think the larger questions we had with the current prototype were around:
ArcSwap
) or leave it to a higher layer? I think most people will have a relatively static authorizer that they want to use with dynamic tokens, and we don't want to rebuild that authorizer on each request. Most people also want the authorizer to auto-update when some external event happens. to give some context, one of the most prominent changes in biscuit 3.0 is the introduction of datalog macros, along with parameters substitution:
the actual authorizer is meant to be different for each request (because ambient facts will be different), so an authorizer will have to be built at each request (either by cloning an existing authorizer or building one from scratch).
based on biscuit middlewares built in other languages (javascript and haskell), as well as based on experience with securing services with macaroons (one of the main inspirations for biscuit)
Based on all this, here is the approach that was used for support on other platforms:
Request -> String
), the token parsing logic ((String, (Option<u32> -> PublicKey)) -> Result<Biscuit, Error>
) and the error response generation Error -> Response
).Request -> Authorizer
function that allows the middleware to perform authorization itself.time()
, …). This step can also load service-wide authorization rules through the use of a macro or a 'static
authorizerParsedRequest -> Authorizer
function can be provided so that the middleware itself can perform authorization itself.See for instance the current work on the actix middleware: https://github.com/biscuit-auth/biscuit-actix-middleware/blob/main/examples/nominal.rs (for now token extraction, parsing and error responses are hard-coded, and it does not yet handle common authorization logic (common authorization logic can be achieved by the users with regular programming techniques).
This structure served me well in production with macaroons for 5 years, and allowed a biscuit deployment in haskell (with the servant web framework) to go through without any modification to the middleware code
Hi,
Thanks for working on this!
Biscuit-auth maintainer here, thanks for working on a tower integration. Are there plans for bumping the biscuit-auth dependency to 3.0.0 / would you welcome a PR doing that?
I have built biscuit middleware for haskell and JS web frameworks, so I'm starting to get a clear view of how to integrate biscuit with web apps / APIs, maybe we could compare notes?