Authentication vs. Authorization: why we need authz standards

I witnessed the transition from bespoke authentication to standards-based authentication. It’s time to do the same for authorization. Here, I’ll outline the difference between authentication vs. authorization and the reason that authz must adopt a common standard.

Twenty years ago, almost everything in the IT world was on-premises: hardware and software, including the tools you used to verify who your users were and what they could do in your systems. In today’s cloud-native world, almost nothing is on-prem, and because of the explosion of apps, remote users and devices, it has become a considerably more complicated task, by orders of magnitude, to verify the identity of a user — or a service — and determine policies that say what they are and aren’t allowed to do. 

Yet, half of that challenge—authenticating a user’s identity—has been mostly solved, or at least standardized. About ten years ago, with the shift to cloud-based applications and remote users, enterprises suddenly needed authentication for each endpoint and app, so there was an explosion of usernames and passwords. Yet, hackers quickly became wise to this scheme, as harvesting passwords and simply logging into the “front door” was much easier than hacking highly secure backend servers. Enterprises needed a way to better protect passwords and logins.

Then came a true paradigm shift: authentication standards became mainstream. For instance, standards like multi-factor authentication (MFA) became ubiquitous, password managers cropped up everywhere, and standards for trusting downstream authentication decisions like SAML, single sign-on (SSO), OAuth and Open ID Connect proliferated. Today, you can’t find an app that doesn’t have a multi-factor sign-in with Facebook or Twitter or Google, for personal use, or business SSO on the commercial side.

Authorization—the other half of the puzzle, the function that says what users and machines can and can’t do after they are authenticated—has largely been left behind. This means that, unlike authentication, authorization policies are still custom-made for each individual organization and application. This is bad. Not only are authorization policies heavily siloed and require extensive manual work to create and maintain, but they don’t scale to support cloud-native architectures, with hundreds of clusters and thousands of services that all need rules for “what can do what.” What’s more, the likelihood of security vulnerabilities is multiplying, as companies ship applications and updates faster than ever, across hundreds of thousands of virtual instances.

During my time at both CA and at Centrify, I witnessed the transition from built-in, local, native, per-service authentication to shared, externalized, standards-based authentication. The security industry must make the same paradigm shift for authorization—with proven, industry-accepted standards that enterprises can easily operationalize. That change is already underway.

To understand authentication vs. authorization, and why authz needs standards, it’s helpful to explore where authorization comes from and why standards for it have lagged, compared to authentication.

In the old world, authorization was fairly limited in scope. Let’s take the Windows-based universe of 20 years ago as an example. Authorization was often described as permissions and Group Policy, and it was challenging but ultimately solvable. In this on-prem, Windows world, Active Directory (AD) would authenticate each user locally—verifying that the user really is who they say they are—and then determine what permissions the user had, once logged in. The permissions piece was built into the Windows domain, and didn’t have to extend to anything else: Can the user access the Windows files she needs? Can she get into her Exchange inbox? Active Directory owned permissions, and it was as simple as rolling permissions into a folder for each role.

Even today, many enterprise professionals still conceptualize authorization as role-based permissions, or else conflate it with authentication under the broad umbrella of identity or credentials — indeed, not as authentication vs. authorization, but authn as authz. However, authorization is an entirely separate challenge for authentication, and requires unique solutions. And, while there were early, pre-cloud attempts at creating standards for authorization, such as XACML, they were never universally adopted, nor extensible. The explosion of vulnerable usernames and passwords was a forcing function for authentication standards; yet, there has never been an urgent need to solve authorization—until now.

In today’s highly dispersed, heterogeneous, cloud-native environment, authorization as it exists is quickly becoming unworkable. A financial institution today, for instance, might have tens of thousands of application deployments, with millions of users and nearly as many roles—and each application requires its own authorization policy, manually created and reviewed. Which roles can access which data? Which microservices can access customer data? What can talk to the Internet? It’s complicated. And, a result of this complexity, application deployments can take months. In fact, it’s not always physically possible for developers to review each standalone policy.

What’s more, every authorization policy is unique for each organization. What does authorization policy look for like a SaaS application like Dropbox? I can tell you for certain that it looks nothing like the policies used by Workday, whose policies, themselves, would be unrecognizable next to those of Wells Fargo. The needs, applications, users and architectures of these organizations are unique, and hence their authorization policies are, too.

Yet, this situation is akin to reinventing the wheel unendingly, because the repeated goal of authorization is always the same: determine which users and services can do what in an app and enforce that policy consistently. Each of these applications could share an authentication mechanism like SAML, because standards for authentication exist. It is high time that we create similar standards for authorization.

Now that every organization is a software company, every app a cloud app and every user a remote user, the industry needs a standard for authorization—establishing the same rules, the same framework, and eventually the same tools that organizations can apply within their applications. And, as with the development of authentication standards like SAML, the industry is already converging around open source authorization projects. Created by Styra, Open Policy Agent (OPA)—a unified policy framework, language and toolset for cloud-native authorization—is becoming the de-facto authorization standard in the cloud. Driven by massive organic adoption in the developer community, it is the only project of its kind currently in incubation in the Cloud Native Computing Foundation (CNCF). 

Regardless of the particular standard that emerges, it is clear where the industry must go. Just as enterprises converged on unified standards for authn, in the authorization vs. authentication conversation, it is time to take the same step for authorization. Not only will standards eliminate the need to reinvent the policy wheel for every app and service, but by creating a shared platform built from the best practices of a global developer community, we can free developers to focus on their true priority: building better, more secure applications. 

Schedule time to speak with us to learn more about Open Policy Agent and Styra DAS! This article first appeared in Security Magazine on August 6, 2020.