Most companies rely on APIs these days. But if small APIs are easily managed and protected, more complex ones need different approaches. As API complexity grows, security solutions should also be developed to match it. We now see instances when solely using OAuth and access tokens might not be sufficient for complex API ecosystems: often, all access tokens issued for an API have the same properties and therefore can be accessed by anyone with the token. This can lead to security vulnerabilities.

Before I discuss how to solve the security challenges of complex API ecosystems, it is important to distinguish between two types of API expansion. Growing APIs can be divided into breadth-grown and depth-grown APIs:

• Breadth-grown APIs grow wide and form a flat system with multiple directly exposed APIs;

• Depth-grown APIs expand in depth, meaning that the system is developed because APIs get coupled together in layers.

Due to the structural differences, the security challenges presented by these two patterns are different too:

1. The challenge with bread-growth APIs stems from the number of exposed endpoints. Typically when proper authorization checks are in place, the bearer of an access token cannot retrieve a different user’s information. However, the bearer can still access any of the endpoints as it might be problematic to secure them all.

   The common solution - introducing scopes to limit capabilities of access tokens - might lead to additional issues such as needing to manage scopes and corresponding endpoints and the complexity of assigning scopes into logical groups.

2. In some depth-grown APIs, the processing of one request usually involves calling many services. When one token is used to secure all downstream services, it can be reused to get access to any API endpoint beyond the set permissions or even be leaked to a third party that can use it to call your API.

To solve these and other challenges, I suggest the following solutions, which one should choose based on the particular needs and your team’s capabilities:

1. Using claims-based authorization

   Scopes are great, but they should not be the only authorization factor. Based on complex authentication information, authorization servers should issue claims for APIs to use them. To limit API access, I suggest using the audience claim. With it, the API can check whether the access token was intended for a specific audience and reject those meant for a different audience.

2. Using token-sharing approaches

   Organizations should consider token sharing to prevent a token from being reused across all services. This usually means implementing token exchange so that a service always operates with an access token tailored to its needs. This limits the potential actions a downstream service can perform. As an alternative, access tokens can be embedded.

3. Using an entitlement management system

Companies with large API ecosystems should consider using dedicated entitlement management systems to mitigate security risks and establish a centralized way of handling authorization. This way, authorization rules will be governed in a structured way and you will avoid unnecessary issues of broken function-level authorization. We suggest using Open Policy Agent, which can be easily set up to work with the Curity Identity Server.

The original article was published on the New Stack. You can read it here.