samjs

Hey James.

Thanks for the feedback, and good catch. Looks like that endpoint is pulling from a slightly out of date data source. The docs/dashboard currently are the best resources for the full catalog, but we'll update that API to match.

Hey jdenquin, author/Oso cofounder here.

I'm obviously biased, but IMO the benefits of using a language over SQL is:

* Ability to write reusable logic (rules)

* Support for inline policy tests

* Abstracted from the data model, so easier for collaboration and distributing across multiple applications

Hey all!

I'm Sam, cofounder + CTO at Oso.

Thank you all for the great discussions going on here. If folks are interested in either learning more about the product or working on these kinds of problems, you can email me directly at sam [at] osohq.com.

Hey cratermoon, Oso CTO here.

I'm probably too close to it, so I'm not following: "a great many of the problems they are solving exist because of RBAC"

Oso supports authorization using any combination of RBAC/ReBAC/ABAC you want.

If anything, I would say that sticking with RBAC is the "easy way" to do it, but you push the complexity of managing it onto your end users (the ones who need to administer it). Whereas building authorization that uses attributes like you describe requires more implementation work, but can make the experience easier for users.

Am I understanding you correctly?

Ah got it, thanks for sharing! That's definitely context I'm missing from having never used it in an actual application.

> I don't really have much desire to get into maintaining an auth library; there's just not enough time in the day!

Haha, well in some ways I'm glad to hear that. That's why we exist :)

> It's pending publish, actually! I've got a devlog (more like a book at this point) for something I've been working on for years now, but no posts are going to be published until I hit a milestone. I'm almost there... not much further.

Send it over if you want another pair of eyes, and lmk when publishing so we can share with our community too. I'm sam [at] osohq.com

Biscuits are really cool, one day I plan to try and convince Geoffroy to integrate Polar for policies :)

Currently Biscuits + Polar are ideologically similar but with distinct use cases at the moment. Oso is a central service that your backend speaks to whereas biscuits are decentralized cryptographic tokens.

So Oso API calls are all done with service-specific API keys, and don't need a proof of identity beyond that.

My mental model for tokens like biscuits is that they work like a "decentralized cache". I.e. you can take an authentication/authorization decision, sign it, and provide it to a client. They can reuse that decision at services without the service needing to reach out to the authN/authZ provider again.

It would play _really_ nicely together with the Distributed Authorization concepts we're talking about here: a client could ask the authz service: "I want a token for managing issues". The authz service/Oso could respond with a partially evaluated policy, like: "this token grants the user access to issues that belong to repository 1, 2,3, or issues that they are the creator" (encoded as facts to check a la biscuits).

When receiving that token, the issues service would know what filtering to do locally, without having to reach out to Oso.

The information passed around between the services mostly stays the same, but rather than make an API call each time, the necessary authz information is encoded in the biscuit token.

And then next level: biscuits can cross federation boundaries and be attentuated, etc. So it really starts unlocking novel ways to integrate application-level authz with infrastructure-level authz.

This sounds really elegant, I love it. Have you seen this deployed in a service-oriented architecture or primarily integrated as part of a single app/db?

(Oso CTO here). Out of curiosity what do you not like about CASL? It always seemed to have a similar goal in mind which I loved, but I suspect it hit similar challenges we had when replying on ORM integrations.