Every application is made up of reusable components. Reusing code increases software development efficiency and helps keep the code DRY. In this post, we compare the different approaches used for reusing software in the context of application authorization.

When it comes to application authorization we can either embed an authorization library, or use an external authorization service. A library will always outperform in terms of latency, as it is part of the application code and deployed with it. But a centralized service will ensure a consistent experience across the application.

These are a few of the considerations to keep in mind when weighing implementing an authorization library vs authorization service. Read on for the full list.

Authorization library: embedded, language-specific code

A library is one of the most commonly used methods of reusing software. The reusable code is developed and released as a library. Implementation consists of embedding the library into the application code.

Being that libraries are embedded, we’ll need to use a library written in the same programming language as the main application. This also means that organizations with a diverse set of applications, or services built in different languages, will need to use multiple authorization libraries to support the different languages.

Casbin and GoRBAC are popular authorization libraries for Golang apps. Flask-Authorize, Flask-RBAC, and Flask-ACL are popular libraries for Python apps. Every language has its own set of authorization libraries.

Authorization libraries generally outperform authorization services when it comes to latency, as they are part of the application. But since the library needs to potentially load and cache a significant amount of authorization data, it may compete for resources (e.g. CPU and memory) with the rest of the codebase, which could negatively impact end-user experience. Conversely, if the data that the library uses comes from a separate system, such as a database, the performance advantages of using a library tend to disappear.

Authorization service: external code, released independently

An external service is the other popular method of deploying reusable code. In this model, the code is developed and deployed as a stand-alone service. The application then makes network calls to invoke the authorization service, using a request-response mechanism.

In the context of authorization, a modern application will call the authorization service as users engage with the application. The application will share user and resource context with the authorization service, which has access to the latest authorization logic and information required to make access decisions. The service will then return an approve / deny response to the application. The application doesn’t need to know anything about the authorization logic, it just needs to call the authorization service whenever a user attempts to access a protected resource.

Given that services are external pieces of software that the application needs to call over the network, they tend to have higher latency and lower availability than libraries. With that said, there are ways we can implement services to significantly reduce this latency. We can, for example, deploy the service as a sidecar, or microservice deployed in the same subnet as the main application, to reduce network latency to the bare minimum.

The external nature of services also means that they do not compete with the application for resources. The authorization logic may also be easier to maintain and update than when using libraries. Any update to the authorization logic or service itself can be tested and promoted to production without requiring we re-deploy the app.

Authorization library vs authorization service

While both approaches to implementing authorization have their strengths and weaknesses, a purpose-built authorization service has some distinct advantages over implementing authorization using a language-specific library, especially for modern applications.

1. Consistency across enforcement points: Modern applications with a microservices architecture will require multiple authorization enforcement points. We cannot expect consistent behavior across enforcement points when using distinct authorization libraries, as there is no central layer. In addition, given that some services might be in different languages, the libraries for these languages are different codebases, so we cannot expect consistent behavior. When using an authorization service, we have a single service to call for any and all access decisions. It can be called using any programming language, and still deliver a consistent experience.
2. Scaling considerations: Authorization libraries are embedded into the application code and deployed in the same process/container. As a result, if we run into CPU or memory bottlenecks, we would need to scale up the application’s host to overcome these challenges. In contrast, we can easily add additional replicas of an external authorization service to boost performance and tackle increasing demand. This is a crucial point, as authorization is on the critical path of every application request. It is even more critical for high-volume applications.
3. Separation of concerns: Given that an authorization service is independent from the application, it can be owned by a different team. We can take authorization out of the hands of application developers and into those of experts (e.g. a security engineering IAM, or platform engineering team). This separation of concerns boosts agility, as it allows the application and authorization logic to evolve independently of each other.
4. Audit trails: The ability to provide audit trails is a key requirement of any authorization solution. Most authorization libraries don’t give much thought to authorization logs, and even the ones that do are inconsistent in how they log authorization decisions. A centralized authorization service lends itself to centralized auditing: since all authorization requests and decisions are made by the service, we can easily collect and aggregate the information required for compliance and audits.

These are the main reasons that modern applications choose to implement authorization as an external service vs a library. See this post for a developer’s account of these considerations.

Conclusion

There are two popular ways to implement reusable authorization code: authorization library vs authorization service. Authorization libraries are easier to integrate into an individual app or microservice, and typically have lower latency and higher availability than services. But libraries, and especially the authorization data they consume, may be harder to maintain than services. And services provide consistency in authorization behavior across services and applications, something that libraries cannot ensure.

Aserto is a purpose-built authorization service. It makes it easy for developers to add resource-level access controls to their applications. It handles all the heavy lifting required to deliver lightning-fast, fine-grained, real-time authorization. And it comes with a complete set of SDKs, quickstarts, docs, and developer guides to make implementation all that much easier.