Advanced API Access Control with BIG-IP APM – Part I

My previous article("Implementing basic OAuth with BIG-IP APM") explained how a user could configure F5 BIG-IP APM as OAuth Authorization Server and OAuth Resource Server. The previous article could show detailed configuration steps for that purpose and how BIG-IP APM can check the attached OAuth token to protect API endpoints when configured as an OAuth Resource Server. The steps I covered in that article should be the first completed when one applies API access control using BIG-IP APM. However, checking the attached OAuth token and limiting the access is not the 'complete' API access control. Why? Because those processes only focus on the 'authentication part' of the 'API Access Control'. In other words, the previous article is still missing the 'Authorization' part of the advanced API access control process. Enforcing the required access policy and checking the assigned privileges for each client is an essential part of the advanced API access control. Please note that more than 70% of the API-related incidents were caused by misconfiguration of the access control or bad API access control methods. In this article, I'll explain how users can configure BIG-IP APM to implement the 'Advanced API Access Control' to protect their API endpoints.

Designing OAuth Scope values

OAuth scope is an essential component in implementing OAuth-based access control for APIs. An organization usually can enforce the required access control based on scope values inside the OAuth access token attached to an API request. If you're unfamiliar with the 'OAuth scope' concept, please read my previous article first. ("Implementing basic OAuth with F5 BIG-IP APM"). Many readers may confuse about the concept of OAuth scopes. I think a 'flight ticket' is an excellent example to explain the OAuth access token and scope values. Let's think about you want to take a plane to move somewhere. You need to buy a ticket first. The staff will check your passport at a ticket counter and give you a ticket for your destination. This process is very similar to what OAuth does for authentication. An OAuth authenticates a user and issues an 'access token' to allow them to access the final destination, which in this case is the 'API endpoint'. Now, you have entered the airplane. However, you realize each passenger is assigned a different seat based on their purchased ticket. A different seating level is assigned on each passenger's plane ticket. Those with more expensive tickets receive more services and more comfortable seats. This is similar to how the OAuth scope works. Once you get an access_token from the OAuth authorization server, you can access your final destination, 'Protected API endpoints', regardless of scope values, because an 'access_token' is the same as a plane ticket. However, OAuth scope defines the different levels of access for each API endpoint, and each OAuth client may have different OAuth scope values based on an organization's access control policy, just like the different seat levels in the airplane. Assigning the wrong OAuth scope to an OAuth client could cause a severe security flaw. If you issue the 'Pilot seat' ticket to a regular passenger, it can cause a terrible disaster. This is why designing OAuth scope values is important in your overall API access control implementation strategy. In this article, I'll explain how you can design your OAuth scope values to implement OAuth-based API access control.

Secure OAuth Scope design

Let’s think of a banking example. The bank in this example has eight different API goals, and you want to secure those API goals using OAuth access control. The bank has two business partners here, the online payment app ‘A’ and financial analytic app ‘B’. Because each app requires different access privileges to the API goals, you want to assign different authorization to each app. For example, online payment app ‘A’ needs to access all 8 API goals for their services, while analytic app ‘B’ only needs to access information-related API goals.

You may want to group these APIs based on their business logic to make the process more efficient. For example, we can group the top 4 APIs under the ‘account’ category and the bottom four under the ‘transfer’ category. Each API category represents an API endpoint; thus, we have two API endpoints now, ‘account’ and ‘transfer’.

The next step is to define the action for each API item. Typically, the CRUD(Create, Read, Update, Delete) approach is used at the API G/W level as an action for APIs. More complex business logic-related actions remain at the application level. Since we’re talking about API access control at the API G/W side, we’re focusing on CRUD-style API access control. The CRUD-based policy can be supported by controlling HTTP methods at the API G/W. The next step is to create scope values using the API categories we defined above(account and transfer) and CRUD actions. With that concept, we can create new scope values like the ones below.

Now, we have eight different OAuth scope values that are attached to each API endpoint. In this example, we created 2 API endpoints and made different OAuth scope values to control each API endpoint’s actions. The benefit of this design is that we can enforce ‘fine-grained access control’ using different OAuth scope values. However, if you have hundreds of APIs defined in your application, the total number of OAuth scopes could be more than a thousand. Enforce access control with thousands of scope values at API G/W may not be easy from the deployment perspective, but I recommend using this design approach if you want to apply advanced API security to protect your applications. The reason is very simple. Because you have to apply those complex access control at some point anyway. In other words, you have to add those complex access control processes to your application code if you don’t add them to your API G/W. However, if your developers have to deal with all those access control policies in their code, it may cause a high possibility of misconfiguration, and it could be another burden for the dev team. If your API G/W can handle a high volume of traffic with many access control policies, you can offload some level of access control policies from the code to your API G/W, and this would be a more efficient access control strategy. However, if your API G/W has no bandwidth to handle additional processing to support many scopes or if your API G/W doesn’t support advanced access control policies with scope values, you can set up a minimum number of OAuth scopes. For example, in the above example, we can create two OAuth scopes for a total of 8 API actions, ‘account’ and ‘transfer’. That means the ‘account’ scope can logically perform all actions for account-related APIs, and the ‘transfer’ scope can do the same for transfer-related APIs. This is known as the ‘coarse-grained scopes’ approach and helps reduce the complexity of an API G/W. However, please note that you have to configure the detailed access control at the application code level if you take this approach in your API G/W.

In part 2 of this article, I'll show you how you can configure BIG-IP APM to apply the advanced OAuth access control using OAuth scopes.