Almost a year ago we start solving a problem that is “boring” for most people and complex. We wanted to build a centralized service that is scalable and fast for all the permissions and access rights in your applications.

But it has been a roller coaster ride so far, let me start with a short intro about us.

We’re 3 engineers from Turkey who moved to the US. My co-founders and I have been building things since high school for 10 years now.

We built many things from small Arduino projects to more recently enterprise software for fortune 500.

In all our projects with these enterprises, we had a main problem. Building a secure authorization system that fits into their systems and is scalable enough for their infrastructure.

We figure out everyone keeps reinventing the wheel. What if there would be an out-of-shelf solution that fits into your identity stack? That was the spark.

We tried many things such as a cloud service that lets you build customizable RBAC, and an OPA control plane. (Yes, I hear you! we worked with REGO 😢)

And eventually, we found Google Zanzibar 😊

Permify is an open-source authorizing service inspired by Google Zanzibar. You can find our repo over here.

We launch Permify as a Google Zanzibar implementation 6 months ago. But a lot has changed in our lives as well as in Permify since then.

We surpass +1k stars on GitHub and +40k downloads. As well as, we relocated to SF.

So, today we’re launching Permify “. I’ll give you a brief summary of what problem Permify solves, what it does, and what should you expect in version 2!

The hard thing about authorization

For most early-stage products authorization is not much of a problem. But it gets hectic when you start growing very fast.

According to the OWASP Top Ten 2021 list broken access control is the number 1 problem in application security.

The main reason is companies are using outdated approaches because they’re too scared to break their authorization system while changing it.

I have seen companies using JWT payloads for their user permissions. And products that created 100 roles to maintain their systems. Which are not scalable and convenient solutions.

Besides these, there are 2 main problems while building your authorization infrastructure; Authorization Logic and Authorization Data.

Authorization Logic

Authorization logic is how you define your permissions and user privileges. And it’s nowhere near a problem when you have simple roles. But simple roles are not enough for many use cases. You can not sustain access control systems with roles that have a larger scope or have relations with other objects in your applications.

So you can end up with a fairly complex requirement that your system can’t handle.

For instance, let’s say you want to create a permission system just like the one in Google Drive. You can assign owners, editors, etc. for each document in your cloud.

A global owner or editor role does not solve this problem. And creating a role for each document does not make sense since you probably have 1000s of documents. That’s a case you can solve with ReBAC (Relationship-based Access Control).

We help you create the last longing logic with “dynamic” permissions with our domain-specific language. So you can easily create user privileges that allow document owners to delete documents but not the editors for any given document.

Authorization Data

The second one is Authorization Data. Once you get beyond monolithic and went into the world of micro-services your data get distributed between. And it becomes uncertain where to enforce your rules.

And since all these application data are also authorization data, it makes your job harder. It becomes challenging to find where the data is and bring it where enforcement happens.

For instance, if you need data from the payment service and identity service.

This is one of the problems that Airbnb suffered from;

Often multiple presentation services that provided access to the same underlying data had duplicate code for authorization checks.

Alan Yao, Himeji: A Scalable Centralized System for Authorization at Airbnb

What is Permify

We help you build granular access control systems and permissions in your applications.

You can simply create an authorization logic. Then set up Permify as a container, and define an authorization database to create a single source of truth.

You own this database. And we log something called relation tuples in this database. Which makes this database work as a source of truth. This helps Permify to become really scalable in micro-service environments.

You can use Permify however you want, but the most common patterns from our users are Sidecar or Centralized Service.

Why Permify?

1. Move & iterate faster by building a flexible authorization system within minutes.
2. Do not reinvent the wheel by leveraging existing, battle-tested code that is inspired by Google’s Zanzibar.
3. Gain visibility across teams observe and work on these permissions as a group.
4. Audit your authorization and ensure Security. Protect your data, prevent unauthorized access, and ensure your users’ security by adopting a least privilege approach.

Version 2 is Out!

Permify is always becoming more stable, faster, and scalable. But we’re making some big steps in our version 2.

Here’s what we are/going to launch in version 2;

1. Multi-tenancy Support: We’re now supporting managing authorization logic from multiple applications. So you can easily create an authorization system for multiple applications in your inventory. Or simply create different custom schemas for different organizations you’re serving your product!
2. ABAC(Attribute-based Access Control): In the first week of March, we’ll be launching our attribute-based access control support to cover more use cases such as restricting access rights based on time, number, or any policy you can think of! For instance, you’ll be able to restrict transactions more than $10,000.00 for some of your users.
3. API AuthN: We're starting to support more advanced API authentications, with latest update you'll get to authenticate between API with a tenant ID that you can insert in the JWT payload. And only thing you need to do is configure your secret key while booting up the Permify.
4. Identity Providers Support: We're starting to support and create integrations with your favorite Identity Providers.

And more to come check our roadmap for more updates.

We're also launching a managed service soon. You can join our waitlist to build scalable authorization with zero-effort!