But Why Authorization Models? Announcing the Oso Modeler

Authorization is a concept as old as computers. Still, it’s not nearly as well described or well understood as other longstanding domains, like databases or monitoring or notifications. This makes it a slog to build a half-decent authorization system. Today, we’re releasing the Oso Modeler, a free technology-agnostic product to help developers design and communicate their authorization models. Using the Oso Modeler, developers can build a picture of their authorization models in less time than a sitting between meetings – a process that would normally take weeks.

But Why Authorization Models?

Authorization is the mechanism in your app that controls who can do what. If authentication is the front door to your application, authorization is about what you can do once you’re inside — what pages you can see, what buttons you can click, what data you can pull. This is something every app has needed since the beginning of time. And yet, as an industry we’re missing not just good technical solutions to this problem, we’re also missing good mental models for how to think about the problem itself.

The first thing most engineers do when beginning to build out authorization is lay out their authorization model. An authorization model is a structured way of describing who is allowed to do what in an application. “superadmins can do anything to anything” is a simple case; that could be one piece of an authorization model. Before you can even start to implement anything, you need to know what authorization model you want to implement.

Is RBAC Really the State of the Industry?

Data modeling, monitoring, notifications – these are well understood domains (just to name a few) that any developer could Google and have no trouble finding thousands of blog posts with mental models and ideas to inform her thinking.

We can’t say the same for authorization though. Many developers have heard of role-based access control (RBAC), maybe attribute-based access control (ABAC), maybe even ReBAC (relationship-based access control). The challenge is that these are high level abstractions – too high level to be useful to the engineer that sits down to write a design doc on how to structure permissions inside her app.

We need better mental models, more and better nouns and verbs to bridge the gap between these coarse ideas and the things engineers need to be successful building authorization systems. How does one get from “RBAC” to “the person who made the file can delete the file” or “you can comment on a file if you own it or if you have commenter access or if you own any of its parent folders”? What’s more, without good models or vocabulary, it’s also hard to communicate internally about how the application is supposed to work.

What Authorization Model are you?

At Oso, we’ve spent 3+ years meeting with thousands of engineering teams to help them structure their authorization models. In the process, we’ve built technology-agnostic mental models for common authorization patterns, which we’ve documented in detail (e.g., in Authorization Academy, The 10 Types of Authorization) and which tens of thousands of developers have already used with great success. And while we love good documentation as much as the next developer, we know that reading documentation requires upfront investment and time.

Enter: The Oso Modeler

Today we’re shipping the Oso Modeler so developers can sit down and get a handle on their authorization model – on their own, without reading the docs, in a single sitting between meetings. Here’s how it works:

1. Start by picking from a set of common use cases that look like they apply to you – e.g., “Sharing.”
2. Next, tell the Modeler about how those use cases work in your application – e.g., “The owner of a file can share that file.” Do this for all the use cases in your application.
3. See the whole picture. The Modeler gives you a structured, English-language version of all the use cases that make up your authorization model, with explanations of how they work and links to more documentation.

It can take some time for engineers to learn different policies and how it relates to the application you’re building. The Oso Modeler is a great teaching tool and makes this process easier for engineers — it doesn’t take a lot of ramp time to be able to understand how to use this product.

Adam Lee, Lead Software Engineer, Chief

This output is not specific to Oso. You can present it at your next team meeting to facilitate a discussion on what you’re planning to build; review it with your product manager to confirm requirements; share it with other dev teams to help them think through authorization; use it to start your next design doc; or even put it in front of your customers for feedback.

Or, you can hit export to Oso Cloud for an auto-generated version of your model in Oso, and get it working right away.

And with that, a process that normally takes 2-4 weeks is done in one sitting. Now you’re the expert, armed with the information you need to make informed decisions about what to build.

We worked closely with the Oso engineering team to develop our authorization model. As we started to understand it, the lightbulbs began to go off. But we did this, human to human, over Zoom. I wish we’d had the Oso Modeler so we could have done this async, on our own, in a tenth of the time. Everyone should be so fortunate to have the Oso Modeler's 'artifact' to bring to their team when getting started with authorization.

Jake Hawkes, Staff Engineer, Sibi

Try it on

To get your customized authorization model, try the Oso Modeler.

And if you have any feedback or questions, you can join us in the Oso Slack community along with thousands of developers working on authorization.

‍