How to choose an Authorization Service?

Before we start breaking the decision process of picking an authorization service, let's, just for the sake of clarity, define what it is first –

What is Authorization as a Service

Authorization as a service (or better-named ‘Permissions as a Service’ to differentiate from ‘Authentication as a Service’) enables software developers to build applications that can request and receive permissions to access certain resources or perform certain actions on behalf of an end-user. These permissions are typically granted by the end users themselves.

By using a ‘Permissions as a Service’ provider, developers can focus on building their application’s core functionality rather than spending time and resources building and maintaining their own authorization and permission management systems.

Learn more about authorization as a service

Don’t Confuse with Authentication

Every developer, when presented with the question: “Do you know the difference between Authentication and Authorization”? Will undoubtedly reply: “Of course!” In reality, you'd be surprised how often they confuse the two.
 
Authorization as a service really (and I mean really) shouldn’t be confused with authentication as a service; which deals with verifying identities (as opposed to checking what they can do or not, once verified).

Some authentication services come with role and/or user management - making you think they include permissions, but these always just translate to claims in your JWT, which still require you to write code to enforce alongside more data points (e.g., billing status, anomaly detection); or worse - they translate into a simple API you query in their cloud - both killing your application’s performance with latency and limiting your ability to upgrade to more complex policies (e.g., moving from RBAC to ABAC).  

Why Should You Use an Authorization Service 

Building permissions as a service is at a critical junction of requiring advanced knowledge in cryptography, cybersecurity, the intricacies of policy models (e.g., RBAC, ABAC, or ReBAC), and high-performance real-time distributed systems - all while not being unique to any product. 

Authorization requirements have a tendency to grow exponentially with the application; starting easy at first (e.g., Admin / Not admin  - hardcoded into the app) but quickly becoming complex with the various requirements from customers, security, compliance, and 3rd party integrations. With new requirements often leading to a full refactor every 3-6 months.

The bottom line is that you should use an authorization service to avoid wasting time reinventing the wheel and avoid making mistakes that can easily translate into vulnerabilities or critical performance issues.

The Key Factors for Choosing an Authorization Service

Compatibility: 

Let’s face it: you probably already have something in place (even if it’s just a single DB table with a user role column). So make sure the solution is compatible with your existing systems and infrastructure. This includes compatibility with your cloud environment, programming language, and data sources.

In addition, you should make sure that the transition to the new solution can be a gradual and fast one (or at least gradual). Gradual means the ability to run the new solution side by side with your existing one and test it behaves as you expect. 

Best Practices:

Anyone can build a service that just returns a list of roles (and many developers do at some point or another in their careers) - but without the best practices baked into the solution, maintaining it, and ultimately refactoring or replacing it would be painstaking and time-consuming. 

Policy as Code, event-driven updates, Gitops, control-plane back office, and customer-facing experiences are some of the best practices you will need and really shouldn’t compromise on. 

Latency and locality:

The average microservice-based application triggers three authorization queries per request. If each takes more than 50-100ms, the performance of your application is basically dead before it even starts to handle its own core logic. Latency across cloud services is basically unavoidable (the service provider might be able to reduce it somewhat but not remove it altogether - especially under heavy workload scenarios).
Hence, it is best to avoid authorization services that provide only remote querying options and that haven’t taken latency into account.

Policy Model Support:

As your application evolves to meet new demands, so will your authorization layer - so while everyone often starts with Admin/Not-admin, RBAC, ABAC, or ReBAC, and variants of them are most likely in your app’s future. Different solutions would support different models and varying levels. 

For example, Google-Zanzibar-inspired solutions are a great way to implement ReBAC but are often impossible to implement or impractical for ABAC.

Scalability:

Consider the scalability of the solution. If you expect your user base to grow significantly over time, you'll want a solution that can handle the increased load and complexity (e.g., of policy or application structure).

Security and compliance: 

Security is always an important consideration, especially regarding access control. When picking a service provider, you should aim for one that has cybersecurity as part of its DNA, building with security by design (and not adding it as layers later). You should ask your provider how they intend to work with your sensitive data for authorization without increasing your attack surface and risk of data leakage.

Ease of use:

Choose a solution that is easy to use and set up. This will make it easier for you to manage permissions and reduce the risk of errors. Remember that this tool isn’t going to be just for your own use - your fellow stakeholders (e.g., product managers, security teams, compliance, support, sales, …) will need to work with this as well. The better you can delegate usage to them, the less of a bottleneck you’d have to be. Prefer solutions that provide user interfaces, as opposed to just APIs and infrastructure.

Support:

Make sure the solution has good customer support in case you have any issues or questions.
I’d recommend taking their support for a spin, asking a question in the solutions community or support forum, seeing how quickly you get a response; or at least glance at how quickly other people’s questions get answered.

TL;DR

Authorization as a Service, also known as permissions as a service, enables developers to build applications that can securely gate access to certain resources or perform certain actions on behalf of an end-user. 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. When choosing an authorization service, compatibility with existing systems and infrastructure, best practices, latency and locality, scalability, and cost should all be considered. It is important to use an authorization service to avoid reinventing the wheel and to avoid mistakes that can lead to vulnerabilities or performance issues.

Have any questions about authorization as a service? Let us know in our Slack community.