Authorization Concepts

Authorization(AuthZ) vs Authentication (AuthN)

While closely related, authorization and authentication are different. To simplify with a metaphor - imagine a person is about to enter your home:

Authentication is about identifying who is at the door and deciding whether they may enter or not.

The Authorization comes in as soon as the person is in your house, and handles their permissions inside the house - can they open the fridge? Sleep in your bed? Read your diary?

To conclude:

• Authentication (AuthN) - Who is the user
• Authorization (AuthZ) - What is the user allowed to do

Dive deeper with this video

Decoupling your policy from your code

One of the key challenges of implementing authorization correctly is to support its ever-changing needs and growing complexity as the project requirements evolve. This complexity can be broken into two main parts - architectural complexity, and feature or model complexity.

Architectural complexity

Naturally, your code evolves as you are adding additional microservices and logic. As a result, additional authorization logic is added ad-hoc to solve specific cases, which eventually leads to inconsistencies in authorizations throughout the system.

Feature and model complexity

Authorization requirements starts with - "We only need an 'Admin' and a 'Not Admin' roles", just to quickly discover that additional roles, models, and rules are required as requirements arrive from customers, colleagues, security, compliance, and partners. Soon RBAC (role based access control) is replaced by ABAC (attribute based access control), GBAC (graph based access control), and/or hybrid models; and more and more access-control features are built on top.

Decoupling Policy and Code in general

To avoid being encumbered by said complexity, we can use the best practice of decoupling policy from code. Ideally, we use a separate microservice to provide authorization to the rest of the system. Open-source solutions like OPA (Open Policy Agent) and its policy language Rego are an excellent baseline for creating such a microservice. Still, it requires maintenance work, especially around connecting the microservice to the application, its policy sources, the data it needs, and the access-control interfaces we need to build on top.

Decoupling Policy and Code with Permit.io

With Permit.io, you get the best in class authorization solution ready-made:

• A microservice that is based on OPA and OPAL.
• A set of SDKs per your language of choice to work with.
• A cloud service to manage it all.

Decoupling Authorization data from application data

While the information for running a product overlaps with the data used to authorize it's access, the two are different. First, the authorization doesn't require all the data used by the application. Second, the data relevant for authorization often extends to additional data sources that are not the application's core, i.e., billing, CRM, identity providers.

With Permit.io, you get a handful 3rd party data integrations from various sources and a pipeline based on OPAL.