Oso Cloud is Generally Available

Today Oso Cloud, our supercharged authorization as a service, is generally available (GA).

 

---

 

Do you remember the first time programming gave you superpowers? Headphones on, notifications off, locked in. Everything is clear. You have an idea, and the computer bends to your will.

For as long as we can remember, building permissions has been a slog…

TLDR

• Vision. We see a future where writing authorization code is fun. Our vision is to deliver superpowers to developers programming authorization.
• What is Oso Cloud? Oso Cloud is authorization as a service – it comes with a declarative policy language for modeling your authorization logic, a cloud service for storing authorization data and responding to permission checks, and developer tooling.
• Why authorization? It’s critical, it’s hard to get right, but it’s core to no one’s business (except ours).
• Why now? Microservices and serverless throw a wrench in traditional authorization architectures. Writing from FAANG companies has shined a light on how much work authorization really is. And the world is moving towards ___-as-a-service.
• Why Oso Cloud? Nearly 1,000 engineering teams have signed up for Oso Cloud already.
  • It strikes the balance between a simple solution — easy to start with, gets you going fast — and one that can handle the full range of complexity that applications need over time.
  • By putting your authorization data in a standard format and describing your authorization model with standard language, you can then ask any question you want.
  • This creates a foundation that unlocks not just support for simple and complex authorization use cases, but also the ability to expose information developers have never had access to in authorization systems, like context-aware logs, debuggers, and more.

---

“Arc is a banking platform, so getting authorization right is critical. We knew our requirements could get complex – we’ve already got 40 permissions across 9 roles – and we wanted to lean on the experts. So, we researched 5 products and chose Oso for 3 reasons:

1. Oso had the most intuitive and clear model
2. Oso was the most mature, with the best tooling and docs
3. The support from Oso has been unreal – almost like tapping someone on the shoulder.”

– Raven Jiang, CTO, Arc

---

“I'm sold on this way ahead for the known future. Oso has nailed the abstractions. That’s the hardest part to get right, and the hardest part to change later.”

– Will Flynt, Principal Engineer, Amazon

---

“Our experience with Oso Cloud has been great – both the product and the team behind it. Its flexibility and how powerful it is are what stand out. And whereas most options we researched would’ve required architecture changes and/or compromises, Oso was easy to integrate and it lets us define exactly what we need.”

– Ali Ziel, Engineer, Spruce

---

We first launched the Oso open source library in 2020. It has since been downloaded millions of times and is used in production at companies like Intercom, Wayfair, Visa, Codecademy, Oxide, Verizon, Optum – everyone from startups to the Fortune 100.

With the Oso library, we introduced Polar, a declarative policy language built specifically for modeling authorization. We also introduced enforcement APIs for checking the most common authorization scenarios, like “Can this user access this resource?” and “What are all the resources this user can access?”

The Oso library was the first step in bringing the world closer to our vision. Today we take another leap forward with the launch of Oso Cloud, which builds on the Oso library and helps solve a new class of problems. Most developers shudder at the idea of picking up an authorization project off the proverbial Jira board. But now when you need to add roles, sharing, fine-grained access, or any other access model to your app, you can use Oso Cloud and feel supercharged. Engineering teams using Oso Cloud typically ship authorization features in 1/10 of the time and rest easier knowing their apps are safe.

This launch is the culmination of 3+ years of R&D, 11 months of hands-on-keyboard coding, and 75+ live reviews with engineering teams.

Nearly 1,000 engineering teams have signed up for Oso Cloud already. To get started, you can sign up for a free account. For more details, read on.

What is Oso Cloud?

Oso Cloud is authorization as a service. Concretely, it consists of the following pieces:

1. A declarative policy language (called Polar) for writing authorization logic.
2. Oso Cloud, the service, which stores authorization data (like roles) and responds to permission checks and related questions over an HTTP API. Our servers are replicated globally for <10ms latency and >99.99% uptime. [1]
3. Clients for most popular programming languages, and a CLI for interacting with our APIs.
4. A UI that lets you interact with our APIs, as well as additional tooling, like a debugger.

Rather than writing custom code and ad hoc SQL statements throughout your app, then stringing them together, Oso Cloud takes you through 4 steps to get a solid authorization system:

1. First, you model who’s allowed to do what in your application using Polar, our declarative policy language for authorization. Polar comes with primitives for common patterns like RBAC multi-tenancy, but is also fully programmable.
2. Then you put your core authorization data – like roles and permissions – in Oso Cloud. You can send any other data (e.g., resource attributes) at request time as context.
3. Next, you add checks in your application using our prebuilt APIs. authorize lets you ask if a user can do an action on a resource. list gets you all the resources a user can do that action on. actions gives you all the actions a user can do on a resource. You can also ask any custom question using the query API.
4. Last, you can monitor authorization decisions in real time using logs. For anything that doesn’t look right, you can use our Explain debugger.

Why authorization?

We’ve spoken with over a thousand teams in 3+ years about their battles with authorization, and 3 patterns are clear:

1. Every application needs authorization. If you can see other people’s stuff, the app doesn’t work as it should.
2. Authorization is hard. Adapting your models is hard. Getting the right data in the right places is hard. Adding checks in all the right places is hard.
3. Authorization is critical, but not core. That is, no one gets out of bed to think about roles and permissions (besides us).

While there are a number of open source projects that have bitten off pieces of the authorization problem over the years, 99% of engineering teams we meet know only one solution: DIY.

We can do better.

Our vision is to deliver superpowers to programming authorization. It’s authorization, supercharged.

Why now?

Authorization has gotten harder in the last decade, and it’s only getting harder still. The introduction of serverless and microservices (or even just N>1 service) throws a wrench in traditional authorization architectures. 10 years ago, all the data you needed for a single authorization decision was right there in your monolith’s database. But that assumption doesn’t hold anymore. This creates a number of knock-on challenges, like figuring out what data needs to go where, and how to normalize authorization data schemas.

In the last few years, a number of high profile engineering teams have also written publicly about the gargantuan engineering efforts they’ve undertaken to solve authorization for themselves. Google, most notably, wrote about its Zanzibar system. Teams from Airbnb, Carta, Slack, Intuit, and others have written similar tomes on their authorization projects, too.

On top of this, over the last 15 years companies like AWS, Stripe, and Twilio have established that if there’s a piece of your application that’s not core to your value proposition, you should offload it to a third-party API or library. Recently this practice has reached deeper and deeper into the application. Developers now use Okta and Auth0 for authentication, which was once thought to be impossible to pull apart from the application. Ditto for usage analytics (cf Segment) and feature flags (cf LaunchDarkly). Authorization is the next layer to go.

In 2022, developers should expect better.

Why Oso Cloud?

Among the many challenges in authorization, perhaps the hardest is striking the right balance between a simple solution — easy to start with, gets you going fast — and one that can handle the full range of complexity that applications need over time.

Oso Cloud provides 3 core abstractions to the 3 big problems in authorization – logic, data, and enforcement – with a focus on striking just this balance.

Logic

Logic is hard because you want to be able to model common patterns – like roles and sharing – easily – while also ensuring you can support the inevitable last 20% that’s custom to your app. You also don’t want to back yourself into a corner and have to refactor the next time you need to add a new feature.

It follows that an authorization system needs simple primitives for the basics, and it needs to be programmable to support the long tail. This is how we built Oso Cloud.

In Oso Cloud, you model your authorization model using Polar, a declarative policy language that we built specifically for authorization. It comes with primitives for the most common modeling use cases, like role-based access control (RBAC), relationship-based access control (ReBAC), and attribute-based access control (ABAC).

In addition to the basics, our Policy Builder provides built-in code for other common patterns, like resource-specific roles (e.g., being an owner of a file), org charts, and file/folder structures.

You can also get these policies and read more about the corresponding use cases in our comprehensive documentation.

One of the reasons that developers have traditionally gravitated towards custom application code for authorization is because they know that there’s almost something you need to do custom for your use case. This is why Polar is fully programmable – for anything that doesn’t fit neatly into a prebuilt pattern, you can program custom authorization logic in Polar. You can use Polar to describe any type of authorization scenario, no matter the complexity of the underlying data. For instance, suppose you want to say that “users can only push to repositories that belong to the user’s organization AND are marked as having org-wide access.” You would write:

has_permission(user: User, "edit", repository: Repository) if
  # Repo belongs to org:
  has_relation(repository, "organization", org) and
  # User belongs to org
  has_role(user, "member", org) and
  # Repository has org-wide access
  has_org_wide_access(repository);

Since Polar is a programming language, that new rule doesn’t need to care why a particular user has a member role on an org or how the repository was marked as having org-wide access — it automatically takes advantage of rules defined elsewhere in your policy.

Data

Data is hard because increasingly you need to bring together data from multiple places to serve individual authorization decisions.

So first, you need a common way to model the pieces of your app’s domain that affect authorization. This includes things like relationships between files and folders, user roles on organizations, usage quotas, resource statuses, time of day, and anything else.

Oso provides a common format that can express any data you want: the fact. Each fact has a name and arguments. Each argument references either a resource in your application (by its type and identifier), or a literal value, like a string.

Here’s an example fact that says that Alice has an “admin” role on the Acme organization:

has_role(User:alice, "admin", Organization:acme)

Here another fact that says that the “Anvils” repository is public:

is_public(Repository:anvils)

Why facts? They provide an opinionated structure to the authorization problem – they ask you to express your data in the smallest possible chunks. Facts support the most common authorization models (e.g., RBAC, ReBAC) without much fanfare, but they’re also generic enough to support the long tail of use cases too, including common attribute use cases like toggles, public/private resources, and user statuses.

Lastly, facts are a good substrate for handling high performance workloads. The data model works well for common authorization queries.

Oso Cloud is optimized to store and query data expressed as facts. When we receive an authorization query, we load the provably minimal amount of data required to check that permission. Latency on most queries in Oso Cloud is <10 ms.

There’s a second challenge to managing data: you have to trade off the benefit of putting more of your authorization data in a central authorization service (easy access for authorization) against the thrust of microservices to separate concerns and keep that data with its originating service for other core use cases (e.g., sorting, filtering). You could sync data to an authorization service but…headaches. [2]

So, Oso Cloud lets you store your core authorization data (e.g., roles, permissions, relations) in Oso Cloud. And for other data that’s not as convenient to centralize, you pass it in as context, which we call context facts. At request time, Oso combines the local data with any shared data and your policy to render a decision. Balance.

Enforcement

Enforcement is hard because it needs to happen in so many places. Controllers, database mappers, routers, and user interfaces all need to check authorization. Anytime you want to update your logic or your database schema, you need to go find all the spots in your code and make sure you got it right.

Oso Cloud puts all enforcement behind a uniform API for checking permissions. You drop these permission checks into your code, and that’s it. Whenever you want to update your authorization logic, you just update your policy.

Your application needs to ask many different types of questions, too:

• “Can this user do this action on this resource?”
• “What are all the resources this user do this action on?”
• “What are all the actions this user can do on this resource?”

Normally you’d have to write different pieces of code in your app with handcrafted SQL for each new question you want to ask. And as above, anytime you needed to update our authorization model, you’d have to go back and refactor those pieces of code individually.

Because Oso uses a declarative language, it can answer these questions with no extra work from the developer. We provide APIs for the common ones: authorize, list, and actions, but if your app needs to ask anything else, you can write a custom query. And this is where it starts to get fun.

When authorization gets fun

The power of SQL is that if you put your data in a standard format (rows, columns, and tables) and give it a schema, you can then query it arbitrarily. 

So it goes for Oso: put your authorization data in a standard format (facts), write arbitrarily simple or complex authorization logic (Polar) – and ask any question you want.

The simplest questions are just the ones described above, and for these we provide prebuilt APIs. These just wrap an underlying allow rule.

But let’s say now we want to ask something like, “What are all of the repositories that belong to organization X AND can be read by user Y?” That’s a custom question that we might ask when filtering repositories for our UI. Oso doesn’t have a pre-built API for that, so you can write a custom query:

can_read_repos_in_org(user: User, repo: Repository, org: Organization) if
  allow(user, "read", repo) and
  has_relation(repo, "parent", org);

If we query:

can_read_repos_in_org(User:bob, _, Organization:acme)

We get back:

can_read_repos_in_org(User:bob, Repo:anvils, Organization:acme)
can_read_repos_in_org(User:bob, Repo:roadmap, Organization:acme)
can_read_repos_in_org(User:bob, Repo:docs, Organization:acme)

We can see there are three results: Repo:anvils, Repo:roadmap, and Repo:docs.

To have done that in a typical DIY system, you’d have had to construct an entirely new authorization check and SQL query. That code would now be code you’d have to maintain and update every time you update any piece of your authorization system, including unrelated components like your authorization logic.

We have gone from the typical wouldn’t-touch-that-authorization-code-with-a-ten-foot-pole to a system that has boundaries and abstractions. A system we can query. A system we can work with and build on.

With this foundation in place, what else can we do?

• Logging, to start. Logs are easy because we have a clear target API (the enforcement APIs), and all of the inputs and outputs are structured and contained. So, Oso Cloud exposes structured logs of all authorization decisions, including all the inputs to a decision (i.e., the facts) and the result of the decision.

• Debugging. Authorization code is branchy by nature. Have you ever tried to step through 50-odd if statements to determine why someone can see a resource they’re not supposed to see? To help you debug these kinds of results, Oso Cloud provides Explain, which shows you exactly why a request succeeded or failed – both the data (i.e., facts) and lines of your policy code that determined the result.

We have a lot more in the hopper, and will share more in the coming months.

What’s next?

There’s a rule somewhere that says we’re supposed to conclude by saying that we’re just getting started.

So here goes: we’re just getting started.

Oso Cloud is a step function change in what’s possible for developers, and perhaps more importantly, the experience of writing authorization code. You can expect us to continue to ship with gusto as we execute on our vision of delivering superpowers to programming authorization. And you can expect us to have fun, too.

Go to cloud.osohq.com and try it free for yourself.

 

 

---

[1] We currently run in AWS across multiple availability zones (AZs), and we add regions and AZs for new customers on demand. You can find more details on the Oso Could architecture in our docs.

[2] One of the lesser known facts about Google Zanzibar is that it became the system of record for the data it stored in Google. It also devoted significant time and resources to building tools to replicate the data back out and reconcile it between systems This is one of they key differences between how Google can implement Zanzibar — enforce a top-down imperative to move to Zanzibar – versus how the outside world can conceive of adopting authorization solutions from third-party vendors.