Show HN: Permify – Open-source authorization service based on Google Zanzibar

We have both worked with fortune 500 companies to small businesses [1], and every authorization system was unique. Yet we always tackle the same problems.

- Modeling the authorization logic was hard. As the product grows things get complicated very fast. So, it’s challenging to design a model that’s both easy to start with and future-proof. [2] - Designing the architecture was a dread. It’s not a huge problem when you have a monolith. But when it comes to micro-services it’s a nightmare since authorization data is a subset of application data. [3] - Authorization checks occur in so many places; like user interfaces, routers, API endpoints, database queries… So, choosing where to enforce authorization, and loading the authorization data is hard.

So, Permify syncs your authorization data as relation tuples with CDC(Change Data Capture) from Databases you want to a DB you point at.[4] And based on this data you can get boolean returns for your access control checks.

I know many alternatives had launched at HN over the course of time. So what’s the twist. What we concurrently encountered was orchestrating the authorization data was a nightmare.

What you can except from Permify in following months;

- Message broker to support more Databases. - Redis Cache support. - Better debugging and auditing tools such as transparency logs. - More compatibility with the Zanzibar paper.

[0]: https://research.google/pubs/pub48190/

[1]: https://www.permify.co/post/why-decouple-authorizations

[2]: https://medium.com/building-carta/authz-cartas-highly-scalab...

[3]: https://medium.com/airbnb-engineering/himeji-a-scalable-cent...

[4]: https://dbconvert.com/blog/postgresql-change-data-capture-cd...

In really simple cases you may model this as a one-shot check on a logical collection resource e.g. If I have an organization, and an organization owns many repositories, I may check for action:read on resource:/organizations/:id/repositories. It's very limiting though. What if I want to list all repositories across all organizations I have access to? What if I have multiple levels I want to cut across? Do I need to do all the sub-queries and aggregations myself? Do I need to do a one-shot check on every potential resource? What if the answer is "no" for every one, and I end up doing a table scan of the entire DB just to produce an empty result set? etc.

[0]: https://blog.warrant.dev/introducing-sync/

[1]: https://docs.warrant.dev/quickstart/setting-up-sync

- Ory came out first with Ory Keto ( https://github.com/ory/keto ) which is trying to be a close adaptation of the paper. Initially, many concepts were missing but they are making a lot of progress with the DSL and it interfaces with the rest of Ory (OAuth2, User Mangement)

- Authzed came out as a SaaS only, open sorucing the code base later on at https://github.com/authzed/spicedb

- Auth0 has been playing around with Zanzibar concepts in various forms and published a beta service at https://dashboard.fga.dev - apparently now also open source parts of it similar to what Authzed did: https://github.com/openfga

- Permify - who on a side note spammed me quite a lot with outreach because I was active in these communities - joins as well https://github.com/Permify/permify

It's exciting to see so much movement, yet also sad that so many companies are brewing their own beer instead of working collaborative on the more succesful projects. Feels like we'll just end up with one or two successful projects (looking at Ory / Auth0 here) with the rest perishing. I'm wondering if there truly is a business model for just this permission system as a saas service (looks like this is what everyone is going with). Here I'm giving Auth0 probably the biggest plus as they have an established identity service. Then again, Okta (parent of Auth0) and Auth0 themselves are not particularly known for good business practices that we usually expect from developer tooling.

What's refreshing though with Permify is that they are trying a bit of a different approach to Zanzibar!

https://github.com/DeluxeOwl/kala-go https://kala.andreisurugiu.com/

It's good to see more activity in this domain. One thing I've noticed over the last several years has been: beyond the fact that we haven't had good options for authorization tools, the world doesn't have enough mental models and good language for describing the authorization _problem_. It's mostly RBAC and ABAC. That is...limited!

As more people work on this problem, I hope we'll continue to build out the collective knowledgebase in addition to having tools that supercharge us. To get the ball rolling, we've written a number of articles, e.g.,

- What is Google Zanzibar (https://www.osohq.com/learn/google-zanzibar)

- Authorization Academy, a series of technical guides on building authorization into an application (https://www.osohq.com/academy)

- Why Authorization is Hard (https://www.osohq.com/post/why-authorization-is-hard)

- Best Practices for Authorization Microservices (https://www.osohq.com/post/microservices-authorization-patte...)

- Authorization Patterns in GraphQL (https://www.osohq.com/post/graphql-authorization)

Onward :)

The Authzed team[0] built Postgres syncing with the SpiceDB Postgres Connector[1] to explore syncing, but we never got it into a place that the community could agree upon. Users in the SpiceDB community are using technologies like CDC external to SpiceDB successfully, but there are many foot-guns to syncing because it can violate data consistency. Is there documentation on how Permify handles consistency (e.g. the Zookies/The New Enemy Problem from the Zanzibar paper)?

[0]: https://github.com/authzed/spicedb

[1]: https://github.com/authzed/connector-postgresql

Do you have any repos with example implementations?