Cómo Proteger tu API Guía de Autenticación


A crucial part of designing the architecture of an API is deciding which data will be public and which will not. Also, what kind of users will be able to access certain types of information. In this article, we will explore different authentication methods, how they are implemented and the advantages and disadvantages of each method. Thanks to all these tips you will discover how to protect your API.


Authentication in an API is the process that verifies the identity of a user or application trying to access it. Therefore, this process is essential to ensure that only authorised users or applications can access the resources provided by the API.

This process serves both to protect access to the API from unauthorised users and to perform user-based access controls. This allows to control that only authorised users can enter and, furthermore, to segregate within those users which roles they can perform depending on the actions.

It can also be used to track who accesses the API and what actions they perform, since, in some types of authentication, the tokens generated are associated with a specific user. In this way, an audit can be carried out to determine whether a user is making suspicious use of our service. This helps to reduce the risk of users making excessive use of resources or denial of service (DDoS) attacks.


It consists of having the information fully exposed to the public, as it is not checked which user is making the request. In this way, anyone using this endpoint can access the information or alter the data stored in the database related to this endpoint.

¿Cómo es una API sin autenticación?

As can be expected, this method does not contain any particularities for implementation.

The advantages are as follows:

  • Due to their lack of configuration requirements, they are simple to implement and use.
  • They have fast access, making them ideal for public services or for retrieving data that does not need to be protected.
  • Because of this lack of configuration they are totally vulnerable to attacks, anyone can access the API.
  • Their use is not recommended for applications that manage sensitive data and much less for any action that could alter the stored data.

In conclusion, such endpoints should be reserved for simple data. Such as a method to retrieve the latest product version number or name, or to retrieve the translation texts of a public page.


La autenticación en una API vía API Key se basa en que el propio sistema genera una clave que, en cada endpoint de la API, se comprobará que esté registrado en el servicio para poder acceder a los datos

The implementation of this method requires several steps. We tell you about them:

  1. The first is that the service provider (API) and the consumer of the provider’s services (client) must be identified.
  2. Once identified, an endpoint must be implemented by means of which, from the service provider’s side, an API Key associated with a specific client is generated with a specific duration of the token. In this way, the system has control over who has access to that API, and until when they can have access.
  3. After this, the user will be able to access the service provider’s application and will be able to see the API Key associated to his application. This can also be done automatically, or after being validated by the provider. This key can then be noted down and all calls made to the service provider from your application can be authenticated.
API con autenticación vía API Key

Each time a call is made to an endpoint, the validity of the generated token is checked, and then any action to be taken by the endpoint is processed.


The advantage of this method of authentication is that it allows access to information to be controlled for a group of users. It is easy to revoke, since a token can be cancelled at any time from the service provider’s application.

The downside is that API Keys give access to the API directly and do not segregate by users. Also, they require several intermediate steps to set it up, such as generating the key at the provider and writing down the key in the client application. It is important to note that any user who has the token will be able to access the data even if he/she is not the user who generated the token.

This type of authentication is reserved for services that will be consumed by other services. For example, an API that presents weather information and a web page that offers data about a specific city.


JSON Web Token is an open standard based on JSON. It creates access tokens that allow verification of a user’s identity, without the need to store additional information on the server.

Authentication using JWT follows a simple structure where:

  • The user authenticates to the application by providing his credentials. For example, by providing a username and password.
  • The application sends these credentials to an authentication server. If the credentials are valid, the server generates a signed JWT token and sends it to the user in response.
  • The user embeds this authorisation token in the header of each request to the API.
  • The API verifies the validity of this token in each call it receives, checking if it is valid, if the user is authorised and if the token has not expired.
API con autenticación vía JWT (JSON Web Token)


The advantages of JWT authentication are that they are signed and encrypted tokens, so the information cannot be manipulated. Since no session information has to be stored on the server, the load stored on the server is reduced and the scaling of the application is simplified. The portability of the tokens is optimal for a microservices architecture, as they are independent of the application domain.

The disadvantages of this implementation are that the revocation of tokens is complex, so that the access of a generated token cannot be removed until it expires. Therefore, until it expires, it can be used to access application resources. But, this can be solved by activating a token refresh method and implementing a reduced token lifetime (e.g. 15 minutes). However, this increases the complexity of implementing this authentication method.


OAuth 2.0 is an authentication standard that allows a user or application to gain limited access to API resources. This protocol does not provide credentials for a user, but issues access tokens to client applications to act on behalf of the user.

This is usually easily identifiable in all services that require a confirmation of access to an existing account of a service provider, such as Microsoft.

API con autenticación vía OAuth 2.0

To implement this, the maintainer must select a service provider. For this example, we will use Azure Active Directory.

First, the application must be registered in the Active Directory, which will generate a JSON needed to make the requests related to the authentication service. This JSON must be stored in the configuration file of our application.

The client application, in each of the requests, will check if there is a token generated by Active Directory. If it does not exist, it will redirect the user to the authorisation server to authorise access. This is handled on the client side in a way that would be stored internally in the web or mobile application.

After the user authorises access, the Active Directory will redirect the user back to the client application with an authorisation code that will provide an access token, which can be reused to make API requests directly.

API con autenticación vía OAuth 2.0


The advantages are obvious, mainly because the user’s credentials are not shared with any application. In addition, tokens can be revoked directly without affecting the user’s credentials. It is therefore particularly useful for applications with multiple users, as it allows for optimal management of the permissions provided.

However, the main disadvantage of this method is that the implementation is more complex compared to the other options presented in this article. The steps where the user has to give consent to access the application can add some time to complete the request. It also requires putting the authentication in the application in the hands of an external service. Therefore, if the external service temporarily stops providing the service, no user will be able to access the application.


This article has presented various forms of authentication to protect access to sensitive data in an API. We cannot say which method is best, as it depends entirely on what the context of the application is.

For example, it would be excessive to set up an OAuth 2.0 authentication service for an API that only returns public data about the different time zones in the world. But it would be interesting to apply an API Key authentication so that only a limited number of people can obtain this information. Which one are you betting on?

Elio San Martín – Software Developer at Itequia