OPA is one solution that's emerged in recent years. The author describes his team's point of view after evaluating it for their purposes.
Oso (https://www.osohq.com/) is a framework for application authorization. Disclosure: I'm a cofounder. Based on the post, the Carta team started their work in 2019, but we only open sourced Oso mid-2020, so they wouldn't have known about it.
And in the last few months, a few other companies have announced offerings to address this problem too.
So it's understandable why Carta chose to build. Now/soon other teams like them should have more options to choose from when they encounter similar challenges too.
You'll often hear people say "you should never, ever build something if you can buy a solution instead" (where buy also includes using an open source package) - but there are actually a bunch of other things to consider:
- Is the solution you're considering well maintained and likely to keep working? Open source projects sometimes stop being updated. Vendors go out of business.
- What's your escape strategy if the vendor DOES go out of business, or massively increases their pricing?
- Integrating with a vendor / package is often a non-trivial amount of development work. Have you considered this relative to building your own, custom solution?
- Do you have specific requirements that go beyond what's available off-the-shelf?
It's absolutely true that your engineering efforts should be spent on the things that make your organization unique: time spent on your customer's problems is more valuable than time spent reinventing a wheel.
But sometimes, the available wheels really aren't fit for your purposes.
I've built when I should have bought, and I've bought when I should have built. Getting it right is hard! Often it doesn't become clear if you made the right decision until several years after you've made it.
Also you avoid vendor lock-in. Even Open source projects cause lock-in especially if they are overcomplex and fast moving.
Carta seems to have an extremely complex authorization scheme but I wouldn't say that's the common case. Many organizations can get by using simple role + account based permissions.
If you are a member of this account then you have access to the resources this account owns minus anything you can't access because you don't have role X or Y. Oftentimes the account based permissions boil down to where clauses in SQL statements. The role based permissions can be mapped to scopes in a JWT or similar.
Anything beyond that can be done with if statements in your "parse user input" function or simply caught later on resulting in a 4XX error.
I know at my particular organization, even when we have cross-account sharing, it's heuristic based. It's simple enough to just apply it in the application code. Stuff like "did this user's organization receive this shipment?"
I feel like you have to be either a very large organization trying to make sure people do things consistently or have a very, very granular permissions model to even embark on making the decision of "build a whole authorization product in house or outsource it?"