When you build an app, you usually have one specific problem you’re trying to solve. It’s essential to be able to avoid thinking about anything that isn’t core to that problem. Thankfully, we can reach for an existing solution for anything we don’t want to think about at that moment.

Dependencies have some integration cost, of course, but really good libraries or services—Stripe is a great example, or PostgreSQL—let us add them with almost no effort. They’ve successfully unbundled their area of concern from user code.

This goes for frameworks, too, and some languages. When they work, when they really get problems out of the way, it feels magical.

Over the last 15 years, many companies have begun to productize that experience.

Why is authorization so hard?

Authentication is the mechanism for checking who you are—like a log-in screen. It’s the front door to your app.

Providers like Okta/Auth0 and Amazon Cognito have APIs for authentication. Authorization is the mechanism for checking what you’re allowed to do—like what pages you can see, what buttons you can click, and what data you can touch.

It’s common to hack together a quick and dirty solution for authorization to start. Usually, that looks like some if statements and roles in a database. That can last a little while until you need to add more authorization features, like role hierarchies, nested objects, and relationships. Any entities that don’t map to a simple list of roles add complexity, and it’s hard to write that code without a plan.

Or, you might want to let customers define custom permissions. Or you might want to go multi-tenant or move to microservices. There might be any number of requirements you didn’t anticipate when, understandably (and often correctly), you started with some basic if statements. When that time comes, your team will inevitably do a big refactor (think six to 18 months) on a domain that’s not central to your business

To get a sense of why this is hard, imagine an application like Google Docs. You have docs that you own. You can view, edit, comment on, and delete these docs. You have docs and even folders that someone has shared with you. Maybe you can edit or just comment on these. There might be other docs for which you only have view access.

The system is controlling access across files and folders, orgs, teams—up and down, at varying levels, and preventing you from seeing docs that you shouldn’t. There are two key aspects of authorization:

The logic is specific to the application itself. How you’d build authorization for Google Docs is different from how you’d build authorization for something like Salesforce or Expensify.

The authorization controls the use of the application’s everyday data, so you’re going to need full access to that data. This means that the authorization system needs access to your application’s data, which will be in a different form for every app.

Every company goes through a custom design process to write custom code to solve its authorization problems. Thousands of companies, solving thousands of authorization problems, every day.

How to make authorization easier

So, if you were going to build an API or a library for authorization, it would need to address the two requirements noted above, along with making life easier for developers. It would need to:

• Be customizable to the application.
• Have direct access to the application data.
• Be generic enough that it actually saves time and effort, vs. developers writing the code themselves.