Authentication is proving who you are to an application or a system. Authorization is the system determining whether you’re allowed to carry out an operation on a resource.

In 2021, authentication is a solved problem. But authorization remains a far bigger problem, and is far from solved.

Then

Why do so many people think of authentication and authorization as more or less the same thing - “auth”? Historically, there was only one place to log in -- your operating system. And the directory component of your OS -- LDAP on Linux, Active Directory on Windows -- was responsible for both authenticating users as well as storing attributes about them, which applications could use to make authorization decisions.

Now

Fast forward to the age of SaaS and Cloud, where there is no operating system to ask. Every SaaS app had to implement both authentication and authorization from scratch.

But single sign-on was too important of a requirement for enterprises. Cloud platforms started offering Identity services, and standards like OAuth2, OpenID Connect, SAML, and JWT emerged to create an interoperable identity fabric. Authentication-as-a-service companies like Okta / Auth0, PingID, and OneLogin take advantage of these standards and provide cross-platform enterprise single sign-on services spanning a variety of identity providers.

Bottom line, authentication is now a solved problem - developers no longer have to re-invent mechanisms for having users prove who they are to their SaaS applications.

What about authorization?

Authorization requires knowing who the user is, so it’s always “downstream” from authentication. But whereas authentication only needs to happen once for every user session, authorization should happen before every operation that is performed on a protected resource.

This is why authorization is so much harder to deliver as “just another cloud service”. Authorization HAS to happen close to your application - otherwise you’re toast.

Unlike authentication, the world of authorization hasn’t moved forward at all. Every application developer has to repeat the same process:

• identify the resources the app exposes (e.g. documents, reports, projects, repositories)
• identify the operations users perform on resources (create, read, update, delete, list)
• design the permissions around these operations (e.g. “read a document”, “delete a report”)
• group these permissions into default “roles” (e.g. viewer, owner, admin)
• provide the administrator of the application the ability to assign users into roles, or allocate custom permissions for each user
• perform authorization checks before performing an operation on a resource, typically using a hand-rolled authorization library or service

While each application may have a unique set of resources it exposes, much of the process of designing an authorization system is boilerplate. Just like authenticating the user can and should be delegated to a standard Identity Provider, the mechanics of performing access checks against an authorization policy can and should be delegated to a standard authorization system.

If you’re not convinced that you want to outsource authorization, just think about the ramp you’re on as your users demand ever-increasing control over authorization:

• finer-grained permissions over resources
• custom roles that combine a different set of permissions than you initially envisioned
• more control over how the organization’s users are “mapped” onto these permissions and custom roles - often using attributes that come out of the organization’s identity provider / directory system
• audit trails of every authorization decision your application makes, to satisfy compliance and regulatory requirements

These are all “heavy lifts” - required work, but not part of how your application delights your core user. In the same way that you use standard authentication-as-a-service offerings to get out of the business of building identity systems, you’ll want to do the same for authorization.

Requirements for authorization systems

So what should you look for? A standard authorization system should:

• seamlessly integrate with standard authentication systems by accepting identity information in a cryptographic token such as a Javascript Web Token (JWT)
• provide a standard language for authoring authorization policies
• map in user attributes from Identity Providers (Google, Azure AD, Amazon Cognito), federated identity providers (Okta, Auth0), and enterprise directories (Active Directory, LDAP) that are made available to authorization policies
• sit close to the application - providing policy decisions at a low latency budget (measured in milliseconds) and at 100% availability (if the application is up, the authorization engine is up)

A great authorization system geared towards developers should also support the following features:

• REST and gRPC APIs for authorization
• SDK’s and language bindings for popular languages and frameworks
• simple conventions for organizing and authoring policies for resources that are accessed using standard architectural patterns (e.g. REST, GraphQL)
• policies that define both access as well as user interface rendering decisions
• components and views for constructing “admin console” functionality for the application

You’ll be shocked to discover that Aserto is such an authorization system :)  Ask us how we can help you get out of the business of hand-rolling your authorization!