Better Off Apart

At FireTail, we’ve been seeing more API breaches this year than ever before. And unfortunately, per our State of API Security 2024 report, this trend is only projected to continue as we move towards an increasingly API-reliant world. 

As anyone familiar with cyber security should know, authorization and authentication are two of the pillars of a strong API security posture. However, as per our report, authorization really takes the number one spot as the primary risk surface when it comes to current breaches and vulnerabilities, and the number of records breached. This comes perhaps from the fact that it is often not fully understood, the overlooked sibling of authentication, so to speak.

So how can we improve authorization in our own security postures? And why is it better to keep authorization apart?

Authorization

Let’s start by going back to the basics: what exactly is authorization? Well, if authentication is how a platform or application verifies your identity, authorization is how the same platform checks its internal system to see what permissions you have, once it knows who you are. In other words, authentication is about who you are, and authorization is about what data you can access, and what you can do with that data.

Zero Trust

A Zero Trust model assumes nothing when it comes to users requesting permissions. It subjects them to checks at every step of the way, to ensure that they are still allowed to perform each set of actions. The Zero Trust method is the internet’s version of “guilty until proven innocent.”

All APIs should be designed using a zero-trust model.

When it comes to APIs, no one should be able to do anything without both authentication and authorization checks. They should follow the pattern P,R,A- principal, resource/action. First, the system must authenticate them as a principal, then it needs to authorize that they can access a resource or perform an action with that resource.

Sometimes the site authenticates you with a 2-factor authentication third-party application, and these methods are widely regarded as the safest. However, less is known about authorization and this too should be outsourced for the strongest security.

We often look at the example of social media profiles when it comes to thinking about PRA. When you create an account on a social media platform, it saves your user data and when you log in, it authenticates whether you are who you say you are. Then, it authorizes that the user you have just confirmed yourself to be has permission to perform each action you attempt from there on.

To illustrate the point, let’s consider two users, Bob and Alice. On a social media app, each of them can create, view and edit their own profiles. Bob is a standard user, and he can also view Alice’s profile. Alice is an administrator, and she can also view and edit Bob’s profile, but cannot delete it. As you can see, from each of those PRA combinations.

Better off Apart

Authorization is often misunderstood. Every BOLA/IDOR incident you’ve heard of is testament to the fact that it is hard to get AuthZ right. It’s one of those things that stands in our way as we uphold the inalienable rights of users to trust in their infrastructure, safety, and security. 

Some of that difficulty comes from entrenched ways of having authZ as part of the application. 

Breaking free of that paradigm, by lifting authZ into the cloud layer, makes security more transparent and easier to manage, and has positive knock-on effects for scalability, development velocity, and maintaining compliance in the face of new and changing regulations. 

Decoupling authentication is already a well understood and widely used approach. Now it’s time to help authorization break free from the app layer.

Every application has its own distinct needs for authorization, using different schemas like RBAC / ABAC or policy engines. Regardless of the system chosen, the common throughline in real world applications is that developers apply the systems piecemeal and in a patchwork manner. 

When new functionality gets built, authorization may be overlooked or set up incorrectly. Even in best cases authorization is often included and mixed in with the business logic itself rendering both aspects of the code harder to maintain and at worst, lead to broken authorization due to accidental or inadvertent code changes.

The solution to this problem is to apply the same architectural pattern to authorization as has been the norm for authentication for some time. Separating authorization from business logic is one of the most effective, sustainable and scalable design patterns for an application. It frees developers to focus on business logic, ensures new features receive correct authorization, and makes the whole authorization process flexible and interchangeable.

Authorization is at its root about three primary factors; the principal performing the action, the action itself, and the resource being acted on. Figuring out these factors and specifying them for your application is a key step. 

Once you have designed and specified your access policy you can use a provider like Amazon Verified Permissions or have a self hosted instance of OpenFGA to implement the scheme and act as the authorization layer of your application. Keeping the authorization graph and policy enforcement separated like this makes it easier to change access policies, or even switch out the underlying system. 

Authentication and authorization are crucial parts of the API, but developers should not be spending time on them. Once an app’s login mechanism is built, it is rarely touched, except to perhaps switch out identity providers. Ideally authorization should be built similarly, as an independent layer. 

Takeaways

API security is constantly changing to become more complex as the cyber landscape continues to grow and new risks continue to crop up. One of the most misunderstood and often misconfigured aspects of a strong API security posture is authorization. Without proper authorization measures in place, individuals can access improper privileges and permissions. However, authorization tends to be stronger when it comes from an outside source, such as a third-party platform, as opposed to in house. 

Overall, API security is a challenging beast to tackle, but equipped with the proper mechanisms such as a strong external authorization posture, it can be much simpler. To learn more about API security, schedule a demo with us or try the FireTail platform out for free, today.