Solving authorization for software developers

I’ve spoken to hundreds of development teams, and most of them still build authorization by hand, ad-hoc, and without a plan. That’s natural—no one has yet developed a “Stripe” or “Twilio” for authorization that solves programmers’ problems.

Following payment processing (Stripe), communications (Twilio), and so many other programmers’ problems that have been carved off and simplified by specialized libraries or services, I believe that authorization, the mechanism for controlling who can do what in a system, will be the next software layer to be unbundled.

And in this post I’m going to tell you why.

The great unbundling

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.

The companies that do this well choose domains that everyone needs to deal with, but that few people want to think about themselves. AWS did this with infrastructure, Twilio with telephony, and Stripe with payments. This only works when the experience is great, of course, which is how Stripe won out over PayPal. As one anonymous developer famously put it, “Stripe doesn’t suck.”

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. Good times.

You wouldn’t roll your own cloud orchestration or payment processing software. So why are most companies still building their own authorization infrastructure?

The answer is that nearly all authorization is custom, specific to every application—and thus tightly entangled with the code and its underlying data. It has traditionally seemed impossible to come up with a generic solution.

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. You get the idea.

What controls all of this is authorization. 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:

1. 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.
2. The authorization controls the use of the application’s everyday data—e.g., who owns a file—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:

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

These are some of the core principles on which we built Oso, an open-source, batteries-included framework for authorization. Oso gives you a mental model and an authorization system—a set of APIs built on top of a declarative policy language called Polar—to define who can do what in your application. You can express common concepts like “users can see their own data,” role-based access controls, organizations and teams, and hierarchies and relationships. Oso lets you offload the thinking of how to design authorization and build features fast, while keeping the flexibility to extend and customize as you see fit.

To design authorization effectively with any system, you’ll want to be familiar with common authorization system designs and patterns. Right now, authorization is an obscure enough topic that it’s difficult to learn about. Google “RDBMS schema design,” and you will get tons of useful results. But look up “authorization design,” and the results will be a mishmash of random Medium posts, heavily SEO’d vendor pages, and a few NIST papers. It’s even hard to find information on how to construct a sensible data model for something like role-based access control (RBAC).

We’re working on solving this education problem at Oso through Authorization Academy, a series of technical guides that explain how to build authorization into an app, whether you use Oso or not. It covers topics like architecture, modeling patterns, and enforcement, which are illustrated using a sample app called GitClub (a GitHub clone).

Oso has been deployed in production systems, from startups like Fiddler.ai and First Resonance all the way to companies like Intercom and Wayfair. It’s written in Rust, and has bindings for most common programming languages. If you find that you need an authorization solution for your application that guides you to best practices, you may find Oso helpful.

Graham Neray is cofounder and CEO of Oso.

—

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.