1: Broken object level authorisation
4: Lack of resources & rate limiting
5: Broken function level authorization
10: Insufficient logging & monitoring
The ability to correctly authenticate users is a critical element of an API. Failure to do so is referred to by OWASP as Broken User Authentication, and it presents a large threat to the API providers and also the users whose data resides within the API. If adequate authentication mechanisms are not in place, then malicious actors can gain access to the API and the data it contains. Exposing sensitive data in this way can harm both the API provider and those whose data is affected.
To prevent broken user authentication, API providers should make the authentication process a primary concern, utilising best practices and thorough testing to validate that the process is secure.
OWASP summary
| Threat Agents/Attack Vectors | Security Weakness | Impacts |
| API Specific : Exploitability 3 | Prevalence 2 : Detectability 2 | Technical 3 : Business Specific |
| Authentication in APIs is a complex and confusing mechanism. Software and security engineers might have misconceptions about what are the boundaries of authentication and how to implement it correctly. In addition, the authentication mechanism is an easy target for attackers, since it’s exposed to everyone. These two points make the authentication component potentially vulnerable to many exploits. | There are two sub-issues: 1. Lack of protection mechanisms: APIs endpoints that are responsible for authentication must be treated differently from regular endpoints and implement extra layers of protection 2. Misimplementation of the mechanism: The mechanism is used / implemented without considering the attack vectors, or it’s the wrong use case (e.g., an authentication mechanism designed for IoT clients might not be the right choice for web applications). | Attackers can gain control of other users’ accounts in the system, read their personal data, and perform sensitive actions on their behalf, like money transactions and sending personal messages. |
Source: OWASP Broken User Authentication
APIM context
It’s common for APIM systems to handle user authentication on behalf of backend systems. In fact, authentication is one of the core elements of APIM from which other functionality stems. Without authentication, the API Gateway cannot identify the client, reducing its capacity to authorise requests and apply other traffic control policies.
Typically, API traffic will be routed such that it must pass through the API gateway before it can reach the API, forcing consumers to authenticate. This removes the burden of authentication from the backend systems.
API Gateways typically support a wide range of authentication methods, allowing them to handle many different use cases. As the technology landscape has changed over time, so too have the demands of the API industry, which has resulted in various authentication standards emerging over the years. Standards such as OpenID Connect and Mutual TLS offer a proven approach for authenticating users, relieving API owners from the burden of building their own solutions, which often introduce additional cost and risk.
Consequently, APIM system must implement authentication correctly:
- Secure data storage: Protect sensitive information by using strong hashing or encryption when storing it in a database. This reduces the ability of an attacker to utilise any stolen or leaked data.
- Adherence to standards: Correctly implement authentication standards, such as validating signatures and expiry dates of JWT tokens. Incorrect implementations are subject to being exploited by an attacker.
- Secure transmission: Utilise secure approaches to transmitting credentials across the network, such as TLS and prevention of using credentials in the URL of the request. This prevents sensitive data from being read by third parties as it is being transmitted over the network.
- Enforce good practice: Deny the usage of weak passwords. Short, non-complex passwords are insecure as they are susceptible to brute-force attacks. Setting a secure password policy prevents weak passwords from being used by enforcing a minimum level of length and complexity.
A common approach for attacking the authentication mechanism of an API is credential stuffing, where large volumes of stolen credentials are used in an automated manner in the hope that one of them will work. This plays to the inclination of some users to reuse the same username and password across many systems. API Gateways can be configured to mitigate this type of attack:
- Rate limiting: Applying strict rate limiting on API endpoints which handle user authentication and related workflows makes it impractical to send the large volumes of requests needed to conduct an attack. However, it’s not an ideal situation. Due to their nature, requests to authentication endpoints are not authenticated, meaning that the Gateway cannot limit individual consumers. This indiscriminate approach affects all clients, whether they are malicious or not.
- Multi-factor authentication: Multi-Factor Authentication (MFA) prevents attackers who obtained correct credentials from successfully authenticating. It does this by using multiple security layers, such as one-time passwords or biometric verification. These additional methods make it increasingly difficult for an attacker to gain access to an account, even if they have the correct username and password.
- Threat detection: Threat detection software which can identify patterns of engagement which correlate with an attack. This allows the system to place restrictions to limit the attack, such as temporarily blocking IP addresses or requiring completion of a captcha.
User authentication is of such importance that it’s become an industry in itself, with many players in the market such as Okta and Auth0. Identity providers specialise in the management of digital identities and their associated workflows, such as authentication. So there’s a natural benefit to combining IdPs and APIM systems, whereby the API Gateway offloads the authentication process onto the IdP, gaining access to the IdPs advanced authentication processes.
Tyk approach
Tyk provides a variety of authentication choices, from simplistic to advanced. It’s recommended to use as secure an approach as possible, favouring methods such as mutual TLS over basic authentication where it’s practical to do so. API owners can choose to use an external IdP by selecting an authentication method which supports this type of approach, such as OpenID Connect, OAuth 2.0 or JSON Web Tokens.
Tyk supports the use of external IdPs for identity management. This enables Single Sign-On, which unifies the authentication process around a centralised trusted source. API operators can choose from a set of commonly used authentication methods, such as OAuth 2.0, LDAP and SAML.
Another IdP-related feature is Dynamic Client Registration, which enables a third party authorisation server to issue client credentials through the Tyk Developer Portal. This allows API providers to operate their Identity Management through a single system, rather than having to manage credentials across multiple systems.
Tyk’s authentication approach is, by default, configured to not allow credentials in the URL. This helps reduce the chance of credentials being inadvertently exposed through back end logging applications. In addition, the Gateway can be configured to enforce a minimum version of TLS, preventing the usage of earlier versions which are now insecure.
