Oso’s CEO says authorization will be the next layer of software to be abstracted and made less onerous for developers. If you ask developers, it can’t happen soon enough.
Want to deliver messaging or voice calls for customers? You’ve got Twilio. Need to process credit card payments? Stripe has you covered. Need to run machine learning models or spin up compute resources or transcribe a podcast or hundreds of other services? They’re just an API away through a cloud provider.
But want to grant or deny rights to users in your application? Good luck.
[ Also on InfoWorld: Programming jobs for losers and how to avoid them ]
Authorization (along with authentication) is one of the most foundational needs of developers when building their apps, but it’s still a colossal pain to deliver. As Randall Degges wrote in 2017, “[A]lmost every time I sit down to build the authentication and authorization piece of my websites, mobile apps, and API services, I get overwhelmed.” This is just as true in 2021, and not just for Degges.
Oso, which just announced its Series A funding from Sequoia, thinks it can do better. Oso offers a library and pre-built integrations so developers can get started fast, while offering the Polar policy language under the hood so developers can customize it however they need. Authorization is “the next layer of software to be unbundled or abstracted,” Oso CEO Graham Neray said in an interview. Any company that can resolve this fundamental developer pain point stands to win big.Which programming language should you learn?https://imasdk.googleapis.com/js/core/bridge3.447.1_en.html#goog_1938440090Volume 0%
Authorization pains
“It seems insane to me that in 2017, if I want to build even a simple website that supports user registration and login, I’m still required to know and understand low-level authentication concepts as well as implement these concepts in a secure and reliable way to protect the most critical data in my application: my users’ personal information,” Degges noted years back. “It doesn’t matter what programming language I use — the experience is more or less the same,” he continued. “I (as a developer) am expected to implement a ton of redundant logic that is mission-critical, deals with highly sensitive information, and can result in massive business losses if I screw it up.”
Aside from that, what’s not to love about authentication and authorization?
Given how fast tech moves, it would be reasonable to assume that we’ve solved this problem in the three-plus years since Degges wrote. Reasonable, but wrong. As Oso’s Neray explains in a blog post, “Despite a lot of progress in developer tooling, developers still roll their own authorization, because there hasn’t been a solution that’s generic enough to be broadly relevant but flexible enough to be useful.”
[ Also on InfoWorld: OPA: A general-purpose policy engine for cloud-native | Using OPA to safeguard Kubernetes | Using OPA for cloud-native app authorization | Using OPA for multicloud policy and process portability ]
Why? Because authorization tools like OAuth and OIDC “burden [developers] with the need to understand how these standards work and how to (hopefully) apply them properly to their application,” as Degges writes in a separate post. Yet “99.99% of developers out there don’t know (or want to know) anything about OAuth, OIDC [OpenID Connect], or any other security specifications. All they want to do is find the simplest and most straightforward way to support user authentication and authorization in their application.”
In the case of OAuth, there’s also the issue of its browser-centricity, as Andrew Oliver notes. “It assumes that the originator making the request can handle an HTTP redirect,” Oliver writes. “This web browser focus is a stumbling block for mobile apps or any kind of ‘thing’ on the Internet of Things.” Yesterday’s authorization tooling, in short, remains far too limited and much too difficult.
Batteries very much included
Despite progress, to Neray’s point, we’re still in the relative Dark Ages of authorization. What would help? Oso wants to dramatically improve life for developers by giving them a “batteries included” approach to authorization, with a policy-as-code language that allows developers to customize as needed, rather than customize by default.
That language is Polar, a declarative language that enables a developer to describe what they want their authorization world to look like and not need to bother with what they need to do to make that happen. Built in Rust, Polar “serves as the foundation for expressing authorization logic, i.e., who can do what in your application,” says Neray.
“On top of Polar, we built a set of APIs and guides to enforce that logic and to model common patterns like multi-tenancy, hierarchies and relationships, plus a debugger and a REPL,” he says. “As a result, developers using Oso spend less time building authorization, which is pretty much the point.”
[ Get the latest news and insights in software development. Subscribe to the InfoWorld First Look newsletter ]
Yet there’s still a lot of work to do. Over the next few months (and years), Oso needs to increase the scope and utility of its libraries and APIs so as to reduce the undifferentiated heavy lifting that developers must do to implement authorization. And, according to Neray, the company also needs to think bigger:
Oso is currently available only as an open source library, but we plan to build on top of the open source library with managed products. Imagine a cloud service capable of powering the Internet’s authorization. To deliver on this vision, we’ll contend with complex distributed systems problems around availability, latency, and data migrations.
It’s a big task, but it promises an even bigger reward, both for Oso and for developers. In early March 2021, Okta agreed to acquire Auth0 for $6.5 billion, which follows on a bevy of other such deals as companies try to conquer authorization to improve developer productivity. That’s a sign of just how much is riding on making developers’ lives easier, one authorized access at a time.
