2938 Members
Join Permit's SlackAuthorization as a Service is a solution that allows developers to manage user access and permissions in applications efficiently without having to build this functionality in-house from scratch. In this article, we'll explore how Authorization as a Service works, its key benefits for developers, and how it simplifies the process of implementing secure access controls in modern applications.
Authorization is the process of granting or denying access to specific resources based on a user's verified identity. (Not to be confused with Authentication, which is about verifying a user's identity). In simpler terms, authorization is about who can do what in your application once they have logged in and under what conditions.
Authorization is a common problem encountered in almost every application out there, with developers most commonly building their own layer to handle these decisions. This layer can be as simple as a collection of if statements embedded in the application logic.
In simpler applications, it is often enough to rely on basic, coarse-grained authorization models like ACLs or Role-based access control (RBAC). The thing is, most modern applications require much more complex and dynamic authorization rules.
Think of a policy like “A user can access this segment of my application if they are a premium user who paid with Stripe and is located in the US”.
While such a policy might seem like a rather basic requirement from an application, it requires quite a complex setup—one that allows making the most accurate access decisions in real time, based on distributed data, and in a way that can be tested, audited, and monitored.
This often requires implementing Fine-Grained Authorization, supporting models like Attribute-based access control (ABAC) and Relationship-based access control (ReBAC).
Authorization as a service allows you to outsource the management of permissions and access control in your application to a third-party service. In the past few years, new authorization providers have emerged, providing a varying set of services and approaches to solving your authorization challenges.
This surge in authorization solutions didn’t come out of the blue, as proper implementation of authorization systems (or the lack of it) is considered by many the biggest concern in application security, with the latest OWASP "Top 10 API Security Risks" report once again listing "Broken Object Level Authorization" as its top 1 vulnerability.
In short, the main benefits of adopting an authorization service are the ability to streamline the application development process while ensuring your application has resilient access control.
This means you can utilize a trusted solution developed by a dedicated team of security professionals, allowing you to concentrate on building the core features of your application, freeing up valuable time and resources that would otherwise be spent on creating and maintaining your own authorization and permission management systems.
That being said, let’s dive into each of these points and discuss it in more detail:
Building a secure application is a top priority for any developer, and managing permissions or authorization is a key component in achieving that. The question of how to manage the authorization layer in your application is relevant to almost any application out there with a varying degree of complexity.
A lot of ink has been spilled over the debate of build vs. buy when it comes to security features. In some areas, such as authentication, a solid consensus has been reached in the last few years that developers should not roll their own authentication. This type of shift isn’t limited to the security space—building your own payment infrastructure instead of using solutions like Stripe has been considered absurd for a while now.
With Authorization, the question of build vs. buy has not been debated as much, as full-stack authorization solutions are only now beginning to emerge.
That being said, let’s go over the main benefits of adopting an existing authorization solution:
While it is possible to build an authorization service yourself, it comes with significant challenges. A homebrew solution would have to meet at least these basic requirements:
If you prefer to avoid the engineering effort, using an authorization service allows developers to focus on building their core application functionality rather than spending time and resources building and maintaining infrastructure, APIs, and human interfaces that aren’t unique to any application.
If you decide to go with an authorization-as-a-service provider, here's a quick list of considerations you should take into account when deciding which solution to pick:
A more detailed explanation of all the factors to consider when choosing an authorization service can be found here.
There is no one-size-fits-all approach to authorization. Each application has its unique requirements, and it’s important to get accustomed to the different solution approaches before making a decision. In general, authorization services can be divided into two main categories: Policy As Code solutions and Graph-based solutions.
Policy-as-code authorization utilizes code to define authorization policies, facilitating their modification and offering a higher degree of flexibility, effectively handling complex rules and relationships. Graph-based authorization systems employ a graphical representation to illustrate relationships between users and resources and excel at mapping hierarchies and nested relationships. To learn more about the choice between graph-based authorization and code-based authorization, check out this article.
Here is a quick list of authorization-as-a-service options:
OPA is an open-source policy engine for controlling access to systems and resources.
It uses a high-level declarative language called Rego to define policies and evaluate complex authorization rules.
OPA has gained significant industry adoption and is backed by a thriving community, making it a reliable choice for building robust and fine-grained authorization services.
AWS Cedar is a new open-source policy-as-code language developed by AWS to streamline IAM management and access control. It introduces a structured and scalable approach to managing permissions, making it a game-changer for application-level permissions. A detailed guide to building RBAC with Cedar is available here.
Permit.io integrates with both Cedar and OPA, allowing users to generate policy as code for both engines.
You can read an in-depth comparison between OPA and Cedar here.
Google Zanzibar serves as Google's gatekeeper for access control and is renowned for its distributed, scalable, and consistent architecture. Underpinning Zanzibar is a graph data model and a distributed consensus algorithm ensuring consistent authorization decisions across the board.
AuthZ’s SpiceDB is a mature open-source graph-based authorization system. Extending beyond Zanzibar's original specifications, SpiceDB introduces features such as Caveats and adopts the role of a permissions database, emphasizing its centrality in the authorization domain.
Scaling the deployment of your policy engine of choice for policy evaluation in production can be challenging.
While policy engines provide the necessary building blocks for defining policies and evaluating decisions, deploying them with your application at scale requires a solution. This is where OPAL comes in. Supporting both Cedar and OPA, OPAL serves as an administration layer that simplifies the deployment of your policy engine of choice and ensures seamless scalability.
With OPAL, you can effortlessly keep your policy configuration up to date across all deployed policy engines, ensuring consistency and accuracy. It also guarantees that the data used for evaluation remains current, facilitating precise policy enforcement. OPAL's configuration-as-code approach simplifies the deployment process by providing a centralized and easily manageable configuration.
While OPA, Cedar, and Google Zanzibar provide us with the ability to unify all policies in a single service, take on the role of policy decision-making and enforcement from the app’s services, and manage policy as code/graph, they lack one key functionality:
The ability to create, manage, and enforce policies in a way anyone in your organization can use.
Normally, creating and managing your application’s authorization policies could only be done through complex R&D work and steep learning curves (e.g. writing Rego or Cedar code). This creates a situation where developers become bottlenecks in your app’s permission management, other stakeholders are locked out of the conversation, and your customers are left without the flexibility they require. All of these manifest as an unending stream of feature requests.
The solution is implementing and managing your policies with a simple, no-code UI that makes permission management accessible to other stakeholders.
This can be achieved by using Permit, which allows you to manage policy-as-code with a no-code UI or API, supporting both OPA and Cedar. Permit generates code for RBAC, ABAC, and ReBAC, which you can edit, add to, and manage via GitOps.
Got Questions? Want to learn more about Authorization? Join our Slack community, where thousands of developers discuss, build, and implement access control for their applications.
Application authorization enthusiast with years of experience as a customer engineer, technical writing, and open-source community advocacy. Comunity Manager, Dev. Convention Extrovert and Meme Enthusiast.
