One of the most fundamental aspects of application authorization is how it is implemented. Is the logic hardcoded or has it been refactored and delegated to an external authorization service? Do we use OAuth scopes vs permissions that are checked in real time? Do we use a local library vs a purpose-built authorization service? And do we base our system on policies vs relationships, or maybe both? In this post, we pick apart the first question.

Most developers start out by hard coding authorization logic into the application code. They do this because it is all too easy to add a case in a “switch” statement here and there, as needed. And that is precisely why one of the first choices they face when it’s time to step up their authorization game is to decide whether to continue and add authorization logic to the code, or to externalize it into a purpose-built authorization service.

There are multiple advantages to externalized authorization vs hardcoded logic. In this post, we describe each option and share the benefits of externalizing authorization into a purpose-built service.

Hard coded rules

Hard coding authorization rules is a very common practice. So common that it almost feels like the natural thing for developers to do. In fact, the average application dedicates approximately 20% of its code to authorization logic - that's about 100,000 lines of code!

The reason that hardcoding authorization rules is such a popular pattern is because it's easy to get started, doesn't require you to deploy a separate system, and doesn't require learning a new language. However, the evolving nature of authorization requirements creates a situation where authorization code is added with time, patch by patch, and sprinkled throughout the application in various locations. The result is what we call “authorization spaghetti code,” which makes it extremely difficult to get a clear understanding of an application’s authorization logic. It also makes administration and governance of that logic a nightmare.

Hardcoding rules also means that every application, or even microservice, builds its own permissions. As a result, every app or service authorizes differently. Lack of consistency in access controls is one of the main reasons that broken access control is the #1 application security risk on the OWASP top 10 list. It is so common that 94% of the applications tested by the OWASP exhibited some level of broken access control vulnerabilities.

If that’s not enough, perhaps the main disadvantage of coupling authorization logic with code is that every change to that logic requires a re-deploy to take effect. This means that any change to access behavior must be prioritized and go through the standard development processes. And it might take several sprints until these changes are implemented.

Now consider a situation where you need to change your authorization logic quickly. Perhaps a change to regulatory requirements, or compliance issues. Regardless, you need to make changes to unblock business opportunities. How many sprints do you think it would take for these changes to go live?

This lack of agility in the context of a critical function, like authorization, is not something that most organizations can afford. Externalized authorization is the solution.

Externalized authorization

Externalized authorization is the practice of extracting authorization logic from application code and expressing it as an external authorization policy (or manifest), managed by a purpose-built authorization service. Expressing authorization logic in an external policy makes it much easier to understand, update, and administer.

Externalized authorization is also easier to reason about and maintain than hard coded systems. External policies can be reused across services to create consistent experiences. This also significantly simplifies access control governance and administration. Gone are the days that a simple change requires prioritization, updates to code in multiple locations, code reviews, and tests. Policies can be handed over to IAM or security engineers who can evolve them independently of the application.

Separation of duties is great, but the ability to change functionality without re-deploying the application is the true power of externalized authorization. An external policy managed by an authorization service allows for changes in behavior based on nothing more than a policy change. Being that the external authorization service has access to the latest policy and authorization information changes in application behavior can take effect immediately and without a re-deploy.

Watch the short video below to see this in action:

Conclusion

Most developers start building permissions by adding authorization logic to the application code. And due to the evolving nature of access controls, this logic tends to be sprinkled in various parts of the code, resulting in a complex soup of authorization logic that needs to be updated and maintained.

While a common pattern, embedding authorization logic within the application code has several limitations vs externalized authorization. In this post, we described those limitations and shared the benefits of externalized authorization.

Whether you’re still debating the options, or have already started working on the next version of your authorization system, we’re here to help! Drop us a line and tell us how we can help, or join our community on Slack.