The landscape of authorization has changed drastically in the last few years - Today’s applications require complex authorization systems and call for well-designed, adaptive solutions. In this post we will try to answer what changed, both in terms of the challenges and the solutions, and how we can adapt to these changes.
But first, before we dive into this - let’s establish the space that we're going to be discussing:
The IAM landscape
IAM (Identity Access Management) is composed of three separate parts: Identity management, Authentication (AuthN), and Authorization (AuthZ).
Identity management
Identity management is about being able to tell who's part of your organization, what attributes they have, and which departments they belong to. This allows you to create identities that can be aggregated and managed in a unified interface.
Authentication
Authentication is all about verifying the identity of the person connecting to your product. These are designated to monitor who has access to the product itself.
Authorization
Once a user has logged in to the product, authorization handles deciding who can do what and in what context within the product.
As you can see, each stage relies on information gathered from the previous one. A more detailed introduction to the IAM waterfall can be found here.
Building (and re-building) authorization
Up until recently, developers have mostly been building authorization by themselves from scratch. As a developer, you might think -
“Ok, so I’ll start off with two types of users: Admin, and non-admin, and make decisions based on this distinction”.
Then, a user comes in and asks you to create an editor role.
So you rebuild your authorization system to allow an editor role.
Later, stakeholders from your company ask you for access to audit logs, and the ability to monitor them on their side.
So you rebuild your authorization system to allow that as well.
Then sales approach you and ask you to create an impersonation tool that allows them to see the system from a different perspective.
And you rebuild again.
Another stakeholder asks you for their own back-office that will allow them to manage new users they onboard into the system.
You see where we’re going with this.
As your product evolves, building authorization yourself requires you to keep rebuilding it time after time in order to adapt it. From the very beginning, you have to ask yourself - Who can access my application, work with it at the infrastructure level, manage it as the developer or work with it as a user? The answer to this question will help you determine how complex the authorization building process will be.
How microservices changed AuthZ
If you look at this issue in the context of the emergence of microservices, it becomes even more complicated. When you built a monolith application, you had the ability to bake in the decision-making process of who connects to what within the application into just one place - usually by using a specific framework such as Spring, Django, or Python. As you start breaking an application into multiple services, you end up having to replicate the authorization code across each and every microservice. And each time you want to restructure, change something, or add another feature, you have to do it in each microservice separately.
The rising demand for increasingly advanced authorization, the rising complexity of the applications themselves, and their migration to microservices and cloud-native structures magnified the pain of building authorization into the application itself.
The good news is that the field of authorization is adapting, and new solutions to resolve these issues are beginning to develop. These become available now thanks to the overall evolution of the cloud space, both in technology and mindset.
Rethinking services, new technology, and a shift-left midset.
There have been a couple of major developments that allow us to view authorization differently: An advancement in technology, a change of approach towards microservices, and the emergence of shift-left and low/no-code developers.
In terms of technology, to create significant changes in authorization we needed the previous layers - identity management and authentication to be working well. Until we had SAML and SSO connect between identity management and authentication, that entire area wasn't stable enough to build upon. The maturity of those standards enabled the entire Authentication space to blossom almost a decade ago, and now again with Passwordless. Before we had standards like the JSON Web Token in the authentication layer, it was basically impossible to connect to it in a standardized way. JSON Web Tokens (JWT), which only became mature in recent years, are a great way to communicate from the authentication layer into the application, and specifically into the authorization layer.
The authentication process ends when the JWT is handed to the application - specifically, to the authorization layer within it. While the authentication layer provides claims that affect the access policy, it's still up to the authorization layer to translate and enforce those claims based on the JWT and, often, additional context data.
In terms of thinking about services, if you go back five years, people were still thinking things like billing, authentication, or databases, being core and critical, require developers to implement them themselves. Thanks to companies like Stripe, Auth0, and MongoDB, developers have realized how complex these issues are, and how problematic it is to try and build them yourself. Thus, a mindset of adopting critical services as part of an application you're building became legitimate. Moreover - it became a consensus that you have to adapt these kinds of solutions since the risk of making mistakes when trying to build them yourself just isn’t worth it.
The overall trend of shift-left, which has been discussed in the security sphere ad nauseam, and the increasing number of people who are becoming low/no-code developers (eg. product, security, compliance) makes it critical for us to enable them to work on such fundamental experiences as access control.
So what can be done about this?
Modern authorization, finally.
This new reality has created an understanding that new solutions to resolve these issues should be built. Thankfully, the developer community has started creating these solutions with open source projects (e.g. OPA, OPAL). This way, you can adopt them as building blocks into your application without paying anything, and more importantly, they allow you to implement practices that prevent you from repeating the mistakes of the past.
The most important matter here is that while building applications, we understand the complexities that come with creating a functional authorization layer, and the best practices that should be implemented while building it in order to avoid constantly having to rebuild them.
There are already good ready-made solutions (e.g. Permit.io) out there - as open-source or as services that you can build upon while avoiding common mistakes. You can also approach this by building it yourself, but if you choose to do so, you have to do it right.
Summary
The drastic changes in the landscape of authorization over the last few years make it necessary for us to change our mindset and adopt new best practices in order to avoid constantly rebuilding authorization. The advancement in technology, a change of approach towards microservices, and the emergence of shift-left and low/no-code developers created an environment in which we can adopt existing solutions and use them as building blocks for our applications.
Top comments (0)