Authentication & Authorization in API Security: Are you doing it the right way?

The Archers API Security Framework helps organisations in defining their API security approach and ambitions, in order to tackle API security risks (including the OWASP top 10 security risks). The API Security Framework logically groups API security aspects together, which allows organisations to define API security requirements and identify required capabilities and components.

In this blog we will tackle Authentication & Authorization aspects, which are important pillars of our API Security Framework. The following questions will be covered:

• Which level of detail should you use to put on authorization rules?
• Where, in your end-to-end flow, should you enforce security checks in order to stop unauthorised calls?
• How can you trust whether your API consumer is who he says he is?

We will highlight the different options and provide insight on how to define the best approach for your organisation.

One of the first aspects you will come across is defining authorization rules for evaluating the decision to grant or deny access to your APIs. Granularity in authorization means the level of details used to put on these authorization rules. Coarse Grained Authorization and Fine Grained Authorization are two concepts that are often used in doing so.

There is a variety of methods for applying the required granularity to control access to APIs. The two most popular access control models are:

• Role-based Access Control (RBAC) – Controls access based on the roles that users have within the system and on rules stating what access is allowed for what users in given roles.
• Attribute-based Access Control (ABAC) – Controls access based on three different attribute types: user attributes, attributes associated with the application or system to be accessed and current environmental conditions.

The main differences are that RBAC makes it easy to establish roles and permissions for a small organisation, but it makes it hard to maintain the system for a big organisation. ABAC on its turn provides more flexibility, scalability and is easier to maintain and support, but is more complex. ABAC requires a higher maturity-level and it can be quite challenging to establish all the policies at the start.

We often get the question “Do we need to opt for RBAC or ABAC?“. Especially now Gartner predicts that 70% of all organisations will use ABAC by 2020, we like to apply the following rules of thumb:

• RBAC is used for coarse-grain access control and ABAC is for fine-grain access controls, but don’t be afraid to combine.
• Evaluate if you need the flexibility and scalability of ABAC, as it comes with an additional cost. The more fine-grained, the more complex.
• Try to use RBAC before ABAC.

After deciding on the authorization rules granularity, you should also make decisions on where to enforce security checks. At first, it seems a good idea to stop unauthorised calls before they reach the API implementation (back-end), the so-called ‘Fail Fast’ principle. However, it might not be sufficient to enforce all checks on your first component as this could open-up your API implementation when you don’t prevent it from being called directly.

We highlight 3 funnelling model options that can be applied. These are indicative, as they will vary in each organisation:

All 3 funnelling models will enforce the required security policies, with the main difference on how fast unauthorised calls will be stopped. Whilst deciding on the funnelling model, you should also take the available security features of each component into account. The available security features are often more limited in back-end servers than the ones available on dedicated gateways. How an API Gateway can help you in this is explained in one of our previous blogs: “Securing APIs … Do we have to consider an API Gateway?“.

The last aspect that we are going to cover in this blog is about authentication factors. Let’s say that you have an API that is secured and only authorised API consumers are granted access. In this case, it is very important that you can trust whether your API consumer is who he says he is. Authentication is the process of proving identity (verifying whether you are what you say you are). Usually authentication is done by a username and password, although there are other various ways to be authenticated.

Authentication factors determine the many different elements the system uses to verify identity. Based on the security level, authentication factors can vary from one of the following:

• Single-Factor Authentication: This is the simplest form of authentication method which requires 1-factor (I.e. username/password, client-certs, JWT token, …) to prove identity. Access to the API can be requested using only 1 factor to verify your identity. For example, only requiring a password against a username would be a way to verify a login credential using single-factor authentication.
• Multi-Factor Authentication: This authentication requires a two (or more)- step verification process to prove identity and request access to the API, preferably from different categories (Username/password, “Its me”, …). It’s a good practice to utilize factors that are independent of each other in order to eliminate any data exposure. This makes it that much harder for hackers to steal valuable and personal data.

When an API must be secured, single-factor authentication can be seen as the minimal requirement. However, this might not be enough when you identify that a higher (more than default) security-level must be applied. Weak or stolen user credentials are hackers’ weapon of choice. Password theft is constantly evolving as hackers employ methods like key-logging, phishing, and pharming. Introducing multi-factor authentication solves this, but also adds complexity. Therefore, you should always evaluate if your API requires multi-factor authentication or single-factor authentication is sufficient.