Authorization As A Service

Heya,

I wanted to talk about about authorization as a service. CIAM often focuses on authentication. Knowing who someone is and allowing a customer or user to get into your system is critical to application functionality.

But authorization, sometimes abbreviated authZ, is just as important. When a user or customer is in your system, what can they do? Of course it varies based on the application, but they typically should be able to:

• view or edit their own data

• control their profile

• access application functionality

On the other hand, they should not be able to:

• view someone else's data

• access admin functionality

• delete data they don't own

There's a ton of nuance in the above two lists, but authorization is critical to ensuring the right people see the right data and can access the right functionality and nothing else.

I wrote about this previously, including sharing a history of access control. Also, here is a nice overview from my employer of common types of authorization models.

Authorization usually is embedded deeply in an application using code or libraries. It may be a series of if/then statements or you might use an open source library like pundit.

However, just as there is value in extracting out authentication, even for a single application, extracting authorization offers benefits. Instead of having authorization decisions entangled in many places in your code, where they are difficult to understand and modify, using a service forces you to extract rules out. You then place them in a service which centralizes them. Doing so often makes them more intelligible and consistent.

Then your application or applications make API calls to the service whenever they need to. This typically happens when the user is requesting protected functionality or data.

One difference is that authentication is logically distinct from your application. Users and sessions are common across many different domains. Authorization is more closely tied to the type of application. Content management systems have different authorization models and needs than calendaring software, for example.

Another difference is that authentication happens relatively infrequently. As mentioned above, authorization needs to happen almost every time a user interacts with an application or API. Such a service needs to quickly answer questions like "Can user X do Y?" or "Can they access Z?".

This means that using a pure SaaS model for authorization is unlikely to work--the network latency is just too high. So open source or on-premise solutions are common. They are embedded in existing application architectures. Examples include OPA, Keycloak, and ORY Keto.

Such authorization services are a layer behind authentication in the user journey, but a critical one. If you want to stay on top of the authorization space, I’d recommend subscribing to the Authorization Clipping Service.

Cheers,

Dan