Why external authorization is essential for modern software architecture

External (decoupled) authorization is the concept of detangling access control logic from application code and delegating the decisions to a centrally managed service within your own infrastructure. This approach is particularly pertinent when considering a move from a monolith to a microservices architecture. However, even monoliths and already established microservices could still very much benefit from decoupled authorization.

Authentication and authorization are often mistaken for one another. Authentication (authn) is the process of identifying who a user is through their credentials. Authorization (authz) is the ongoing process of ensuring that the user is allowed to perform the actions they are trying to do.

Authentication is relatively isolated from the application as all it needs to do is verify that the user is who they claim to be and securely maintain that established identity until the session ends. In contrast, authorization is deeply entangled with the application code as every action performed by the user needs to be checked to ensure that it is allowed in that context.

In addition to knowing who the user is, the access checks need to consider many other factors such as the action being performed (e.g. create, delete, update, send), the state of the resources (e.g. who owns the resource, which geography is it located in), and the business logic surrounding those actions (e.g. only managers can approve expenses).

Authorization is absolutely necessary for any non-trivial software project. Because of this, it’s almost inevitable that authorization logic gets directly woven into the code. This approach will work perfectly well if the application is feature-complete; however, the reality is that software rarely stays static. Requirements change, new features are added, new regulations are introduced, operating scale changes, development team structures change, new technologies and architectures are introduced—all these constant upheavals create massive headaches for engineers as well as other stakeholders when the authorization logic needs to be updated.

Further problems to consider:

• Developers have to trawl through the entire code base to find the dependencies and occurrences of the logic being changed. This is because access rules need to stay consistent across the code base in order to not create security loopholes or vulnerabilities. Even though the original change would have been expected to be localised, it would soon spiral into a tedious and error prone quest to keep the entire code base consistent. Feature development takes longer than expected as a result.
• Copy-pasting of existing code and slightly modifying it to achieve a subtly different effect is a practice that often crops up in these code bases that are in constant flux. This further complicates the updates as each occurrence needs to be carefully studied to ensure that no unintentional bugs are introduced.
• Oftentimes, no automated tests are available or the available tests don’t cover all the eventualities. This creates uncertainty and toil as the changes have to be painstakingly tested manually with no guarantee that all cases have been covered.
• Identical logic needs to be implemented multiple times in polyglot environments because different components are developed in different languages or frameworks. Ensuring consistency and correctness becomes difficult.
• Deployments become complicated due to dependencies between different components and needing to ensure that they all enforce the same rules.
• Audit logs and other observability and auditability features are either not implemented, or implemented inconsistently across the system.
• No documentation, and a lack of visibility into the access rules implemented by the system.

External authorization aims to address these issues by eliminating the duplication, extracting volatile business logic into centrally manageable and versionable policies, and providing ways to comprehensively test and deploy those security policies independently of the applications and services that depend on them. This is usually achieved with a dedicated policy decision point (PDP) that runs within your infrastructure as another service or as a sidecar that provides an API for obtaining authorization decisions. Stateless PDPs can be easily scaled horizontally to handle growth and are more secure because of the small security footprint.

Due to being an API, a PDP can be integrated into any stack with minimal effort. Industry groups such as the AuthZen working group are already working on defining standards for these external authorization APIs, which should trigger the development of library abstractions and ease any transitions between different vendors in the future.

The biggest return from investment on external authorization is the policy repository which is now the single source of truth for authorization logic within your organization. Even non-developers should be able to read and understand the rules that are implemented, which is of immense value in regulated industries where external auditors need to be convinced about security controls in place. This increased visibility makes planning easier and development quicker as well.

Comprehensive test suites can be built for the policies to ensure that they are working as intended. Workflows can be built to review, approve and deploy new changes from a single place rather than having to do that multiple times for each application or service affected.

With all access decisions being made by the PDP, it’s in a unique position to generate comprehensive audit logs and metrics for every action happening within the system. These logs are tremendously useful for debugging, security investigations and compliance efforts such as ISO certifications.

Implementing external authorization does not come for free as it requires some work to migrate the system to the new way. However, this can be done incrementally in stages with testing and validation guardrails in place. Even within a single application or service, it’s possible to start with a minor component and then gradually increase coverage until the whole application or service is operating with external authorization. The whole system does not need to be converted at once, which makes planning and executing the transformation much easier and non-disruptive.

If you want to dive deeper into implementing and managing authorization, join one of our engineering demos or check out our in-depth documentation.