How to secure your APIs

Published in

API Integration Essentials

5 min readMar 18, 2020

Photo by King’s Church International on Unsplash

We all know how important is API Security. If we look at today’s world, most of the businesses use APIs to connect services and to transfer data. Sometimes this data is more sensitive and it could be someone’s medical information, financial information or some other personal data. So not all data is the same and should not be protected in the same way.

Sometimes you don’t care if someone finds out what’s in your fridge, but if they use that same API to track your location, then you might be more concerned.

So there are four main options that you can use to secure your APIs.

Basic Authentication

This is the most straightforward method and the easiest one. With this method, the sender places a username and password into the request header. The username and password are encoded with Base64. One thing to note down here is your credentials are encoded, and not encrypted! Due to this, it is easy to retrieve the username and password. We should not use this authentication scheme on plain HTTP, but we can use this via HTTPS.

Basic Authentication does not require cookies, session IDs, login pages or other such specialty solutions, because it uses the HTTP header itself. Also, this does not need to do any handshakes or follow any complex response systems.

So basically it is recommended to use basic authentication for securing APIs where you have a system to system communication that happens in an internal network. So this could be an IoT solution use case.

One of the drawbacks of this method is that there is no policy on refreshing the user credentials. If the user changes the user credentials, then you need to change your client applications as well.

OAuth2

Source: https://blog.restcase.com/restful-api-authentication-basics/

As we discussed previously, Basic authentication had several issues and also some security vulnerabilities. Those issues have been solved in OAuth2.

OAuth 2 (Open Authorization) is an open standard for access delegation. It is used for token-based authentication and authorization. In this approach, the user logs into a system. That system will then request authentication, usually in the form of a token. The user will then forward this request to an authentication server, which will either reject or allow this authentication.

From here, the token is provided to the user, and then to the requestor. So hereafter without the user, this token can be used or can be validated over time until it is expiry. This token has a scope where it defines the limit of where the token can be used. You cannot use the same token for all the resources of the APIs if it is bound with a particular resource. Once the lifetime of the access token expires, the requestor has to refresh the token to obtain a new token. So there is a token refreshing mechanism when compared to the basic authentication.

This is fundamentally a much more secure and powerful system than the other approaches, because of the scope and validity period. This standard is used by many technology providers, such as Google, Facebook, and Twitter.

There are several grants for a client application to acquire an access token. There are grant types such as client credentials, authorization code, password grant, NTLM, SAML grant and refresh grant.

Password grant is similar to Basic authentication where you need to use your credentials to get an access token. The strongest grant type is the authorization code grant type.

An OAuth2 access token can reside in two forms. That is an opaque token and JWT access token. The JWT is a self-contained access token where it contains all the required information to validate an access token. When you provide an opaque access token, the gateway has to call key manager to validate the access token. But if the access token is JWT, the gateway itself can validate the access token without going to the key manager. This is very important in a locked-down environment where gateway is not connected to other components.

The drawback of this OAuth2 option is that client applications have to implement the access token retrieving, refreshing the access token, etc. So this is somewhat complex for the client application.

API Keys

API Keys can be used by applications that are unable to develop an OAuth2 flow. In this method, a unique generated value is assigned to each first time user, signifying that the user is known. When the user attempts to re-enter the system, their unique key is used to prove that they’re the same user as before. Based on the API key implementation of different API Management providers, the key can be changed. Sometimes it could be a JWT access token or it could be an opaque token or a consumer key of an OAuth2 application.

API key can be sent as a header as well as a query parameter as part of the URL. When sending as a query parameter, it is easier to discover for any attackers. So using it as a header value is more secure.

API keys are widely used in the industry and became some sort of standard due to its simplicity. But this is not a good security measure. API keys are recommended to use a system to system communication.

Mutual SSL

Source: http://www.middlewareplus.com/2016/

When we compare the usual one way SSL authentication where a client verifies the identity of the server, in mutual SSL the server validates the identity of the client so that both parties trust each other. So in this case, API gateway and the clients that connect to it are well known.

This securing option is recommended to use where it requires tight security and between server to server communication.

Best option to secure your APIs

This depends on your use case. When selecting an option among basic auth, Oauth2, API keys, and mutual SSL, you need to consider a few things.

Do you require tight security for your system?
Is it a system to system communication?
Do you need access delegation?
Does the communication between the API Gateway and the clients happen in an internal network?

Based on your situation, you can pick any of the security mechanisms discussed above.

You can try out all these security options in WSO2 API Manager.

Try these and let me know your feedback.