biscuit-rust VS oso

> We have a post on this coming soon! The short version is that Polar is a logic language based on Prolog/Datalog/miniKanren. And logic languages are a particularly good fit for representing the branching conditional logic you often see in authorization configurations.

Ha, I've been playing around with Biscuits (https://www.biscuitsec.org/) and was writing up a blog post on using them in a git forge. When I saw the Polar data units described as "facts" and read your end to end example (https://www.osohq.com/docs/tutorials/end-to-end-example) I thought "Oh this looks very similar". I will say - I do like how Polar seems to type stuff and provide some concepts that Biscuits force you to build out on your own, that's pretty neat.

What is the proof of identity in Polar? Is it something like a token in Biscuits? I'm curious if you can do things like add caveats to reduce what the token is capable of as it gets handed off to different systems. I consider that one of the "killer use cases" of biscuits.

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.

> The point of JWT vs opaque tokens is that you can just inspect the token itself to derive permissions without hitting any sessions in DB, right?

As I understand it, de-centralized verification isn't a necessary characteristic of a JWT. There are token constructions that make that a priority, however[0].

[0]: https://www.biscuitsec.org/

a C compatible library thanks to cargo-c

I like the Datalog-based policy language used in Biscuits.

https://www.biscuitsec.org/

Has anyone tried https://www.biscuitsec.org/ ?

I haven't seen it much discussed, and seems to solve a lot of issues from JWT

Link to GitHub -->

Not OP but Authentication is easy, authorization is a cross-cutting concern that often requires custom code. E.g., there are people and teams, both of which can have different kinds of access to something (read/write). Sometimes teams have sub-teams. Do the sub-teams have access to the parent teams' resources and/or vice versa? Also what kind of sharing are you going to support? Do people have to have an account to view stuff shared to them or can you just send a link? There are some efforts to make custom DSLs for describing authorization policies, to avoid cross-cutting code[1].

Computed fields require different treatment at every level of the stack. This isn't inherently hard, but it is an extra feature these low-code/no-code platforms need. Where things get difficult is inn migrations. It's common for a field that is computed at the beginning to become customizable, or for the computation to change. When that happens, what should the value be for old columns? Computed fields also often pull data from multiple other tables, which may require some combination of custom queries and database optimization.

[1] https://github.com/osohq/oso

Oso and OpenFGA are two alternatives that implement Zanzibar-style authorisation.

There's Oso as well

Well this was fun to see! I'm the CTO of Oso, where we're building Polar (the second of the links mentioned https://docs.osohq.com/).

I have a few really minor nitpicks, so will try and make up for it by adding to the discussion :)

First of all, it doesn't really make sense to talk about Datalog as a good language for authorization, because much like with Prolog there doesn't really exist a single implementation of it. OPA's language Rego is a datalog variant, and Polar started out as a Prolog variant (although it's not really recognisable as one any more).

And that's an important point because otherwise it would be pretty reasonable to decide that: logic programming is good for authorization => you should go find the most battle-tested language out there and use that. For example, there's SWI Prolog [1] and Scryer Prolog [2] as two of my favourites.

To me, the thing that is mind-blowing about logic programming, is (a) how powerful the paradigm is, and (b) how concisely you can implement a logic programming language. Take miniKanren [3] which is a full-blown logic language in a few hundred lines of code.

In my mind, the original article makes a decent case that logic programming is a good fit for authorization. And just generally I love anyone bringing attention to that :)

But to me, the reason logic programming is such a solid foundation for authorization logic is the pieces you can build on top of it. For Polar, we've added:

- Types! So you can write authorization logic over your data types and help structure your logic. We've implemented this by simply adding an additional operator into the language that can check types

First time hearing about rhai, but there's a project in that space called Oso that's authored in Rust and uses a different DSL than Rego. You may or may not find it appealing.

Authentication is probably the aspect of it that's the weakest. Authorization has a few nice libs, with Oso probably being the nicest, but authentication is mostly roll your own from what I've seen.

> Hopefully Oso open source their library.

https://github.com/osohq/oso seems to have the core, C FFI, and language bindings.

Thanks! PHP is a highly requested language for us and we've been rolling them out based on demand. You can vote for it if you want here https://github.com/osohq/oso/issues/791