Why authorisation is the next big technical challenge

Graham Neray (Oso)

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.

Authorisation (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, “Almost every time I sit down to build the authentication and authorisation 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 customise it however they need.

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

Authorisation 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 authorisation?

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’sNeray explains in a blog post, “Despite a lot of progress in developer tooling, developers still roll their own authorisation, because there hasn’t been a solution that’s generic enough to be broadly relevant but flexible enough to be useful.”

Why? Because authorisation 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 per cent 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 authorisation 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 authorisation 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 authorisation. What would help? Oso wants to dramatically improve life for developers by giving them a “batteries included” approach to authorisation, with a policy-as-code language that allows developers to customise as needed, rather than customise by default.

That language is Polar, a declarative language that enables a developer to describe what they want their authorisation 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 authorisation 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 authorisation, which is pretty much the point.”

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 authorisation. 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 authorisation. 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 US$6.5 billion, which follows on a bevy of other such deals as companies try to conquer authorisation to improve developer productivity.

That’s a sign of just how much is riding on making developers’ lives easier, one authorised access at a time.