Skip to main content

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 will deal with identifying who is at the door and deciding whether they may enter or not.

The authorization will start immediately as soon as the person is in your house. It will deal with the person's permission once they enter - can the person open the fridge? May they sleep in your bed? Can the person read your diary?

To conclude

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

Decoupling your policy from your code

One of the key challenges of implementing authorization right is to support the ever changing needs and the growing complexity from authorization as the project requirements evolves. Authorization complexity can be broken into two main parts - architectural complexities and feature or model complexities.

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, or 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.

Multi-tenancy

Most modern applications, especially microservices-based ones, require some degree of multi-tenancy:

  • Allowing a secure and compliant access separation
  • Allowing the application to serve multiple customers at once - while sharing the underlying infrastructure and services
  • Allowing for load balancing and scaling

An authorization layer is the most robust and fastest way to upgrade from a single-tenant application to a multi-tenant application safely. By applying a policy across all the relevant services, the authorization layer can apply the needed separation without requiring changes to the services themselves.