Oso is a company building an open-source authorization engine, and its blog covers authorization design and its Rust implementation.
One commenter calls it a very interesting company in authorization with a great blog; others cite its guidance on negative permissions.
> neither of the solutions you called out has been out for more than ~1 year,
That's a good callout. These are still early days when it comes to Zanzibar & co, and all implementations are very new. I'm glad different implementations exist. This will allow the community to experiment with multiple ideas and allow them to flourish or be discarded.
Authzed's idea Jimmy linked to elsewhere (Caveats) [0] is not in the Zanzibar paper, however it is an interesting option to try to tackle ABAC scenarios within a Zanzibar context.
OSO (and Aserto seems to be doing the same) is approaching this the other way - they have a good Policy/ABAC solution, do they benefit from a more Zanzibar-like approach to the AuthZ problem, the answer seems to be also yes (OSO Cloud [1]).
In OpenFGA, we dropped the concept of Zookies. Will we regret this? Time will tell. SpiceDB bet on the importance of Zookies, and in some cases they are right. We also added support for having multiple model versions active at the same time and some ABAC scenarios through Contextual Tuples [2] (less powerful than caveats, but more Zanzibar-y). Is that a good idea? Hopefully!
That's the beauty of it, there are considerations (pros and cons) for all of these approaches, users can pick and choose what works best for their situations. We will all learn and adapt. We may all end up discarding some of our assumptions and adopting new ones. Ultimately this will benefit all of us, and more importantly the wider audience and…
*Old problem, new $25B+ market*
Companies like AWS, Stripe, and Twilio have shown that if a technology isn't core to your value proposition, you should offload it. Still, every engineering team builds and rebuilds one piece: authorization, how you control who has access to what in your app. We intend to change that.
We see a world where developers never roll their own authorization again, and instead say, "Just use Oso" – the same way you might say, "Oh, you should just use Postgres for that." In doing so, we're creating the $25B+ authorization market.
*Why Oso?*
We have the lead – in traction, capital, and team.
- Traction: Oso is used by thousands of companies from startups to the Fortune 500, like Wayfair, Arc, Intercom, Visa, Oxide, and Codecademy.
- Capital: We're the best-capitalized, with 4+ years of runway from the world’s best investors, including Sequoia, Felicis, and infrastructure entrepreneurs like Olivier Pomel (Founder, Datadog), Dev Ittycheria (CEO, MongoDB), Arman Dadgar (Founder, Hashicorp), Edith Harbaugh (Founder, LaunchDarkly), Guy Podjarny (Founder, Snyk), Paul Copplestone, (Founder, Supabase), Christina Cacioppo (Founder, Vanta), and Calvin French-Owen (Founder, Segment).
- Team: We've spent 3+ years going deep on the domain. We've met with thousands of engineering teams and know more about this problem than anyone. And we have two of the best developer go-to-market leaders on earth who have done it before at MongoDB at Snyk.
*Why now?*
We're…
Oso | Engineering Leader, Software Engineer, Developer Experience Engineer, Product Leader | New York City (NYC) | Onsite or Remote
Over the last 15 years, companies like AWS, Stripe, and Twilio have helped developers offload anything not core to their apps so they can focus on what matters to their users. Despite a lot of progress in developer tooling, most developers still roll their own authorization.
You might start with something quick 'n dirty – some IF statements and roles in a database, which may not be pretty but gets the job done...until you need to add more features, and more features. And inevitably every team band-aids onto this system until they do a big refactor. This is lost time for an area that's not core to what most companies are trying to solve for their users, and what's more, no one on the team is feeling great about this work.
At Oso (backed by Sequoia), we're building the first batteries-included framework for authorization so developers don't have to roll it on their own ever again. We're designing slick APIs to cut down the amount of time they spend getting their system set up, and building a fully-fledged policy engine and programming language (in Rust) under the hood to ensure they can customize their system however they need. We don't have any product managers – the engineers on the team are responsible for taking broad problems, experimenting with potential solutions and shipping a superhuman experience for our users.
The team members who…
Oso | Software Engineer, Developer Advocate, & Eng Manager | New York City (NYC) | Onsite or Remote
Over the last 15 years, companies like AWS, Stripe, and Twilio have helped developers offload anything not core to their apps so they can focus on what matters to their users. Despite a lot of progress in developer tooling, most developers still roll their own authorization.
You might start with something quick 'n dirty – some IF statements and roles in a database, which may not be pretty but gets the job done...until you need to add more features, and more features. And inevitably every team band-aids onto this system until they do a big refactor. This is lost time for an area that's not core to what most companies are trying to solve for their users, and what's more, no one on the team is feeling great about this work.
At Oso (backed by Sequoia), we're building the first batteries-included library for authorization so developers don't have to roll it on their own ever again. We're designing slick APIs to cut down the amount of time they spend getting their system set up, and building a fully-fledged policy engine and programming language (in Rust) under the hood to ensure they can customize their system however they need. We don't have any product managers – the engineers on the team are responsible for taking broad problems, experimenting with potential solutions and shipping a superhuman experience for our users.
The team members who join now will not only have a…
I think the most important place to start is appreciating the distinction between authentication ("is the person trying to use my application really the person they say they are?", abbreviated "authn") and authorization ("is this person allowed to perform the action they're trying to perform?", abbreviated "authz").
Most of the comments on this page are referring to authentication. It's important to know, but also the piece you're likely to spend far less time on. It's where most of the heavy lifting will be done by some vendor or tool you set up instead of by your own code.
Authorization is far less likely to be something you get off the shelf and far more likely to be where you spend significant time. It can be very intimately connected to your business logic. Active Directory roles and groups are one authorization solution for a particular class of problems but I have only seen them used for controlling business internal assets (mostly file servers); not public-facing applications.
I really like Oso Academy as a resource for authorization topics. It's structured like a progressive course, though I don't know if they have the kind of exercises you mentioned.
https://www.osohq.com/academy
> do you have an opinion on which enterprise-grade AuthZ provider works best with Supabase?
Since you asked for my personal opinion, then I would say Postgres Row Level Security for AuthZ. RLS is as powerful as it is flexible. It's fully-integrated with the rest of the Supabase stack, and it's portable if you don't like supabase - just pg_dump and take it to your favourite Postgres provider.
That said, I understand why it's useful to have something more structured like RBAC. We have experimented with a ideas here (specifically ABAC), using a custom libraries/extensions/custom claims[0]. We do something similar internally, but aren't 100% happy with the developer experience and don't plan to release it any time soon.
I'm sure the Auth team won't enjoy me saying this, but I like the idea of Zanzibar. I've seen some experimental Postgres extensions[1] that combine Oso[2] + RLS which I'd love to try when I get time.
[0] custom claims: https://dev.to/supabase/supabase-custom-claims-34l2
[2] Oso + RLS: https://github.com/MFAshby/rls_oso
[1] Oso: https://www.osohq.com/