It’s increasingly evident that for security to work, security must be baked into the development process — not a bolt-on afterthought that a dedicated security team manages. This newfound appreciation for developers’ roles in security has given rise to things like DevSecOps as well as open source projects like Oso.
What is Oso?
Oso, which just announced today the general availability of Oso Cloud, offers an open source policy engine for authorization that represents security as code so developers can express security as a natural extension of their applications.
Authorization is among the most foundational needs of developers when building an app, but it’s still a massive pain to deliver. As Randall Degges wrote in 2017: “Almost every time I sit down to build the authentication and authorization piece of my websites, mobile apps and API services, I get overwhelmed.” True then; true now.
Authorization is hard to get right, and while crucially important, it’s not necessarily central to anyone’s business. As such, authorization tends to be something that every company requires yet often goes about in ineffective ways. Arguably, it’s time we stop thinking about authorization, or security in general, as an off-the-shelf product that someone can buy, and more about a new model or mindset that developers must apply.
Oso, much like Okta and Twilio before it, thinks it has a way to help.
The problem with microservices
Every application needs authorization. If you’re using an app and can see other people’s sensitive information, the app is worse than broken. The problem is that everything about authorization is hard.
But while nothing about authorization is easy, it’s also true that everything about authorization is important, even if authorization doesn’t tend to be core to any particular person’s job. This may have been okay in a monolithic app world, but it is definitely not okay in a microservices architecture.
SEE: Identity theft protection policy (TechRepublic Premium)
Traditionally all of the requisite data for a single authorization decision was there in your monolith’s database. This is no longer true in a microservices world, which results in a number of challenges, including the figuring out of which data needs to go where, and how to normalize authorization data schemas.
Just as the so-called FAANG companies were among the first to push toward microservices architectures, so too are they first to detail the difficulties of authorization in a microservices environment.
In recent years, some of their engineering teams have written publicly about the exceptional engineering efforts they’ve undertaken to solve authorization for themselves. Google, most notably, wrote about its Zanzibar system. Just outside the FAANG cloister, teams from Slack, Airbnb, and more have written similar posts on their authorization initiatives, as well.
While these companies may choose to build their own authorization policy engines, that feels increasingly futile or, at least, like overkill. In the last decade or so, technology leaders like AWS, Stripe and Twilio have established that if there’s part of your application that isn’t core to your customer value proposition, you should offload it to a third party that specializes in that component. This started with things like compute, but the trend keeps inching closer to the app. Little (Okta split out authentication) by little (Segment separates usage analytics) by little (LaunchDarkly with feature flags), the trend moved deep into application code.
This brings us to authorization. Authorization has so far evaded becoming a third-party service offering, largely because no one has been able to make it generic enough to be broadly relevant while still being flexible enough to be useful. Oso thinks it has cracked that code.
Undifferentiated heavy lifting of authorization
Oso launched as an open source library in 2020. For many, including me, the response was cautious: It still felt a little strange to “outsource” authorization to a third party, even if companies were doing a somewhat shoddy job of handling it themselves.
But in the intervening two years, developers have downloaded Oso millions of times, with companies like Intercom, Wayfair, Visa, Codecademy, Oxide, Verizon, Optum and many more running it in production. As Arc CTO Raven Jiang put it, some even embraced the idea of leaning on an authorization expert to meet their needs: “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 nine roles — and we wanted to lean on the experts.”
SEE: Mobile device security policy (TechRepublic Premium)
Those “experts” need to go beyond software and challenge the model for delivering authorization, said Graham Neray, Oso co-founder and CEO, in an interview. Doing so helps both established enterprises and stealthy startups “ship authorization features in 1/10 of the time and cut the risk of operating these systems.”
But what is this “model” he referred to? Well, if databases have document or relational models, and programming languages have object models, surely there must be a model for authorization? Thus far, the answer is “no.” But that’s a problem, as developers think in terms of models.
Some developers, Neray said, may have heard of RBAC or ABAC. More cutting-edge developers may have heard of Google’s Zanzibar. None of these really handle the core problem. What does work, Neray continued, is to think of authorization as composed of three core abstractions — logic, data and enforcement — and “once you understand how each of them works, you can build (or adopt) structured solutions that let you bend authorization to your will.”
In practice, this means it’s a bit like SQL, where if you put your data in a standard format and give it a schema, you can then query it arbitrarily. In a similar manner, in Oso you put your authorization data in a standard format, write arbitrarily simple or complex authorization logic, and then can ask any question you want.
Enter Oso Cloud
As announced today, Oso Cloud is now generally available and consists of the following pieces:
- A declarative policy language called Polar for writing authorization logic
- Oso Cloud, the service, which stores authorization data and responds to permission checks and related questions over an HTTP API
- Client APIs and a CLI for interacting with our APIs
- A UI that lets you interact with the Oso APIs, as well as some additional tooling, like a debugger
If this sounds risky, the company replicates its servers globally. As for trusting such a critical component of an application infrastructure to a third party, we’ve seen this play out in other categories, as noted above. Plus the company is composed of veterans who have operated critical infrastructure for companies like Veritas, Symantec, Intercom, Lacework, Puppet, Betterment, Gremlin, Mailchimp and more.
But really, it comes down to whether a little bit of trust is worth the removal of a lot of bother from your application infrastructure. As Oso co-founder and CTO Sam Scott stressed: “Our vision is to decrease the amount of time and brain calories that developers spend thinking about authorization by 10x in the next 10 years.”
Disclosure: I work for MongoDB but the views expressed herein are mine.
