In our previous “Authentication & Authorization in API Security: Are you doing it the right way?” blog we have been talking about the importance of the Authentication & Authorization pillars of our API Security Framework. As APIs establish an important channel to your enterprise’s systems, data, and services. It’s important to keep focus on API security to prevent business/reputation loss, competitor’s gains and so much more. There are numerous aspects that you must consider in securing your APIs.
When it comes to securing APIs, you should always start by defining your requirements. Based on these requirements, you can define the best solution. It is very important to evaluate the chosen solution in order to guarantee that your requirements remain fulfilled. There are many industry standards available to accomplish this. Leveraging on such industry standards will make the embedding in your landscape more easily. However, you are likely to run into challenges and hurdles. Especially in a more diverse and complex landscape, which will require some specific decisions or deviations.
In this blog, we will tackle Authentication & Authorization aspects. The following questions will be covered:
- Which industry standard is commonly used in securing APIs and why?
- Which is a common challenge we see in diverse and complex landscapes?
- How can you cope with this challenge, without lowering the requirements?
We will highlight different aspects and provide insight on how to define the best approach for your organisation.
Which industry standard is commonly used in securing APIs and why?
Let us start by defining which requirements we are going to use throughout this blog. We opt for the 2 most commonly used, being the Client and End-user authentication/authorization.
A very simplistic solution would be to use the Client/End-user credentials to perform the API call. However, this would be quite a security risk, since the credentials are provided to another system. This is an example of the “Password Anti-Pattern“. In practice, this solution cannot be used. OAuth 2.0 offers a solution for these type of scenarios without the risks of the password anti-pattern. With OAuth 2.0 we can give access rights, without providing the passwordin every request or to the API resource. Instead, a token is handed out.
In our “Securing APIs … Do we have to consider an API Gateway?” blog, we provide insight into the role and the added value of a gateway component.
The Client/End-user will authenticate against a STS-component. The main responsibility of the STS component is to verify that the Client/End-user is who he says he is, but also to verify if access to the resource can be granted. After the verification was successful, a token will be issued which will be used to perform the API Call. This token will contain information about the Client and End-user and is issued by a trusted security (STS) component. The token can thence be used to fulfil our Client and End-user authentication/authorization requirements!
What is a common challenge we see in diverse and complex landscapes?
Although we used an industry standard in the above example, you will still need to take some specific decisions within the boundaries of the industry standard. In for example, you can choose to do explicit token validation on both the API Gateway and API Resource. Which implies that all your back-end technologies must have OAuth 2.0 support and support the OAuth Remote introspection functionality!
Take a quick look at your organisation’s application landscape and put it to the test. Unfortunately, the illustrated situations are not uncommon as the main suspects will be Custom Development in older technologies, Commercial Of The Shelf (COTS) packages and even SaaS solutions! So… the more diverse and complex your landscape is, the more likely you will identify all the above cases as relevant.
How can you cope with this challenge, without lowering the requirements?
All the above illustrated situations can be coped with in different ways. We position the API Gateway as a KEY component in all possible approaches, as this will limit the impact to the API back-end side only. By doing this, you will have no impact on how the Client and End-user will authenticate and prove their identity!
So… which approach could you take to cope with this challenge, without lowering the requirements and limit the implications?
The API Gateway will perform most of the security checks, hence the importance!
Let us start with the situation we see most often, the back-end has NO OAuth NOR any other token-based mechanism support.
- Possible solution: The API Gateway converts the OAuth (token-based) security mechanism towards a specific mechanism (I.e. Basic Authentication). The API Gateway will extract the Client and End-user context from the token and issues the information through the message-body
- Implication: The token, containing the Client and End-user identity is no longer used. This means that the trust-level is no longer on STS-level, but on API Gateway level. This is typically not the best practice, but often allowed as the API gateway is positioned as a component which can be trusted. Notice that there are severe limitations on what the back-end can validate.
The second situation we see often, is where the back-end has NO OAuth support, but DOES support another token-based mechanism.
- Possible solution: The token will be transmitted from the API Gateway towards the back-end. Which can abstract the Client and End-user context from the token for security validation purposes.
- Implication: The Client and End-user identity remains inside the token, which means that the trust-level remains in STS. However, there are limitations on what the back-end can validate.
The third situation we see, is where the back-end DOES support OAuth, but ONLY with their internal STS.
- Possible solution: We typically don’t want the end-user to authenticate twice (on different STS components, so the API Gateway will use a Token Exchange Pattern to authenticate against the other STS.
- Implication: The Client and End-user identity remains inside the token, which means that the trust-level remains in STS. However, this is a more complex solution.
- Warning: The suggested Token Exchange Pattern is not always supported on their internal STS. In that case you step down towards Basic Authentication and we suggest to immediately switch to solution 1 or 2.
Conclusion:
We walked you through some Authentication & Authorization aspects of API security and highlighted that:
- The use of an industry standard to fulfil your requirements is always a good idea.
- The use of an industry standard often leads to compromises in diverse and complex landscapes.
- Possible solutions are available to cope with these challenges, without lowering your requirements.
- You must be aware that alternative solutions might have some implications and that different solutions also require to be governed and supported over time!
Do you have any questions after finishing this blog post about API Security? Or do you like to have advice on this or other challenges you face? Let’s chat! It would be a pleasure to see any use of our API Security Framework in your architecture work to achieve secured APIs!
ALWAYS LOOKING FORWARD TO CONNECTING WITH YOU!
We’ll be happy to get to know you.
