In the previous article, we saw that it was better to authenticate with username and password to access the endpoint published through https, than to access a completely open endpoint published by http, although few were those who knew the url.

The configuration that we introduce in this third issue of the series, will save you from having to send the user data and the password in the communication with the endpoint.

Use a single-use key

An alternative to always using the same username and password, is the possibility of using a single-use encrypted key, which enables access to a resource.

For this, we must use an algorithm that, based on some input data, generates this encrypted key. Both the connection client and the receiver must be able to validate that the key is correct.

This mechanism is called authentication based on “Digest“.

The conversation between the client making the request and your endpoint begins with the request for access to the resource, to which the endpoint responds with an ‘Unauthorized’ message and parameters (realm, cnonce, qop) generated for this request, that the client must capture.

Next, another new request is generated, where a hash generated from several operations with the received parameters and other own ones are sent, such as username, nonce, uri, nc, being nc and nonce generated by the client uniquely for this request .

Although it may seem more complex, actually there are few additional operations to other methods. But with this we managed to avoid a serious problem, which is that someone who has captured the traffic can make the same calls as an authorized customer, from their own application.

Even so, it continues to falter in certain aspects. In the end, we must store the password on the server where the endpoint is published and someone could get it.

How do we add a Digest-based authentication to your balancer?

We have to keep in mind that for nginx to allow this type of authentication, we must install a module that has not been fully validated: “ngx_http_auth_digest”, and the instructions are detailed in this link (2).

To make sure that the module is available in your installation, you can run the “nginx -V” command, as shown below.

And in Nubentos, How do we use the Digest based endpoint?

It’s as simple as selecting the corresponding option when adding it in the “Implement” tab.

Display “Show more options” and complete the “Endpoint Auth Type” field with the “Digest Auth” option, and enter the username and password.

In this article, we have developed the basic configurations to secure access to an endpoint. There are other more complex and secure mechanisms such as OAuth2, OpenID and JWT, which require the use of specific frameworks for the development of the API, and a greater complexity of the necessary infrastructure.

Nubentos provides these mechanisms by default to API consumers, therefore they are not necessary for the interconnection with the API provider’s endpoint.