APIs are the core building blocks of digital businesses—assembling data, events and services from within the organization, throughout ecosystems, and across devices. Now with organizations moving more of their business online in the wake of COVID-19, those APIs are increasingly being exposed to external groups, whether to other departments, customers or enterprises in their partner network. This exposure not only raises the stakes for protecting users and data but also makes APIs more vulnerable to security attacks.
In light of these changes, it is important for software architects and developers to review the API security mechanisms they have in place with their API management implementations and evaluate whether it’s time to put more robust protections in place. Let’s look at the four main authentication approaches to securing APIs as part of an API management implementation, as well as options to augment these approaches either during the design or runtime of an API.
Basic authentication is the easiest and most straightforward method. The sender places a username and password into the request header, and the username and password are encoded with Base64. This authentication method does not require cookies, session IDs, login pages, or other such special solutions, because it uses the HTTP or HTTPS header, itself. It also doesn’t need to do any handshakes or follow any complex response systems.
The simplicity of basic authentication means it can be an appropriate method for securing APIs where you have a system-to-system communication that happens in an internal network, for example with an Internet of Things (IoT) solution.
However, basic authentication comes with some caveats. First, credentials are encoded and not encrypted. As a result, it is easy to retrieve the username and password. For this reason, developers should only use basic authentication on HTTPS, not plain HTTP. Additionally, with this method, there is no policy on refreshing user credentials. So, if the user credentials are changed, the client applications need to be changed as well.
Open Authorization (OAuth) 2.0 is an open standard for access delegation that is used for token-based authentication and authorization. With this approach, the user logs into a system, and that system requests 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 the authentication.
From here, the token is provided to the user, and then to the requestor. Hereafter, without the user, this token can be used or can be validated over time until it expires. This token has a scope defining the limit of where it can be used, so the same token cannot be used for all the resources of 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 one. So there is a token refreshing mechanism when compared to the basic authentication.
Fundamentally, OAuth 2.0 is a much more secure and powerful system because of the scope and validity period. This standard is used by many technology providers, such as Google, Facebook, and Twitter.
There are several grant types a client application can use to acquire an access token, including client credentials, authorization code, password grant, New Technology LAN Manager (NTLM), Security Assertion Mark-up Language (SAML), grant, and refresh grant. Password grant is similar to basic authentication where a user needs to use their credentials to get an access token. Meanwhile, authorization code is the strongest grant type.
An OAuth 2.0 access token can reside in two forms: either an opaque token or a JSON Web Token (JWT). JWT is a self-contained access token that contains all the required information to validate an access token. When you provide an opaque access token, the gateway has to call the key manager to validate the access token.
By contrast, with a JWT access token, the gateway itself can validate the access token without going to the key manager. This is very important in a locked-down environment where the gateway is not connected to other components. The drawback of this OAuth 2.0 option is that client applications have to implement the access token retrieval, refresh, etc., making it somewhat complex for the client application.
API Keys are a popular option as it requires less effort than developing an OAuth 2.0 flow. In this method, a unique generated value is assigned to each first-time user, signifying that the user is known. Each time when a user tries to re-enter the system, their unique key is used to verify that they’re the same user as before. Based on the API key implementation of different API management providers, the key can be changed. It could be a JWT access token, an opaque token, or a consumer key of an OAuth 2.0 application.
An API key can be sent as a header as well as a query parameter as part of the URL. However, using it as a header value is more secure, since sending the API key as a query parameter makes it easier for any attackers to discover.
The API key approach is widely used in the industry and has become somewhat of a standard due to its simplicity. And, while API keys are recommended for use with system-to-system communications, they present too many security risks when used for authenticating users.
In mutual Secure Sockets Layer (SSL) authentication, a client verifies the identity of the server, and the server validates the identity of the client so that both parties trust each other. Using this approach, both the API gateway and the clients that connect to it are well known. Therefore, it is recommended for use in scenarios requiring tight security and/or server-to-server communications.
Determining the best authentication option for securing APIs will depend on the specific use case. Key questions to consider are:
1. Is tight security for the system needed?
2. Are either system-to-system or server-to-server communications involved?
3. Is access delegation required?
4. Does the communication between the API gateway and the clients happen in an internal network?
Authentication is at the heart of securing APIs. But, depending on how extensively an API is used, it is worth considering further API security measures to measure how secure an API is or flag if there is a potential API attack.
One approach is to audit the Swagger definition of an API before publishing it. With technology like API Security Audit from 42Crunch, an API developer can get a report on how secure the API is based on OpenAPI format requirements, security, and data validation. Using the report, the developer can eliminate any existing security loopholes in an API by tracking exactly where an issue is and taking corrective actions.
Another approach is to use artificial intelligence (AI) based security analysis at runtime to detect any attempted attacks. Here, the API gateway will intercept API requests and apply any policies as usual, but it will also send API request metadata to an API security analysis tool, such as PingIntelligence for APIs. The AI-driven tool will check the validity of the request, search for any abnormal access patterns, and confirm if the request is OK or if it is suspect and therefore needs to be blocked by the API gateway.
Examples of API attacks that can be reported and blocked using this approach include credential stuffing attacks on login systems, botnets scraping data, layer 7 distributed denial-of-service (DDoS) attacks, stolen cookies, tokens, or API keys; and rogue insiders exfiltrating data in small amounts over time.
Early business surveys and our own discussions with customers across a range of industries suggest that their expansion of remote collaboration and communications, automation, and digital product and service offerings will become the new normal. With APIs driving many of these uses, now is a good time for architects and developers to re-evaluate and update their API security strategies.