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.

, 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 , 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 .

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 .

Copyright © 2021 IDG Communications, Inc.

LEAVE A REPLY