Security

Security should be done over HTTPS in all cases, among which there are generally three very widely used approaches: API-Key-based, Token-based or certificate-based APIs.

API Key-based Authentication

In API key authentication, an individual key is issued to the client, usually a string of alphanumeric characters. The length varies, but the longer the better.
The server receives the API key, which is usually located in the HTTP header. The key is then checked for validity with a key store - for example a DB. If the result is positive, the server responds with the corresponding request.

The advantage of this method is that it is very easy to implement and does not require any other services, only a database for matching. The disadvantage is that simplicity becomes a problem at the same time when it comes to more complex scenarios. Furthermore, a key loss is very problematic, because misuse can only be prevented by a complete blocking.

Token-based Authentication

With token-based authentication, it is common for the client to first obtain a token for authentication: the id_token. Usually, an extra authorization server is responsible for this.
With the id_token, the server now logs on to the Authorization Server and asks for a token for a specific API: the access_token.
The API can now be requested with the access token, whereby the API itself trusts the Authorization Server and thus also the token. There is no additional validation via a database.

The advantage of this method is that it is very powerful even for complex scenarios. It is also a very big advantage that the responsibility of creating the token takes place at a central location and is decoupled from the actual API resource server. The tokens also enable very fine-grained authorization options, for example through claims. Since a token has only a short lifespan, its loss is not quite as bad as with an API key, but is still problematic.

The downside is that this is a relatively complex scenario with multiple services, which itself must also be well organized to ensure token validity. Real-time validation of the tokens requires very many HTTP calls.

Nevertheless, due to the enormous advantages, this method is the recommended way, along with OpenID and OAuth2.

Docs: Implement authentication in .NET microservices and web applications

Certificate-based Authentication

In certificate-based APIs, both the server and the client have appropriate certificates to identify each other.
When the client connects, the server checks whether the client’s certificate is known and valid. If the result is positive, the connection is accepted and the client receives the response.

This method is rarely used on the Internet due to certificate handling, but it is certainly used for closed backend systems.

Docs: Configure certificate authentication in ASP.NET Core

About HTTPS

When it comes to security, special care must be taken to ensure that no information bypasses the HTTPS encryption. This means that all sensitive content must be transmitted either via HTTP headers or via the HTTP body. The query values are not part of the encryption and can be seen from any point in the data transmission despite HTTPS!

The header should always be used in authentication.

GET /articles HTTP/1.1
Authorization: Bearer S0VLU0UhIExFQ0tFUiEK

or

POST /articles HTTP/1.1
Authorization: API-Key S0VLU0UhIExFQ0tFUiEK

Similarly, it would be safe to transmit content through the body at certain endpoints where no other content is otherwise transmitted. This is also secure in HTTPS.

POST /authentication/reset HTTP/1.1
{
    "API-Key" : "S0VLU0UhIExFQ0tFUiEK"
}

Never transfer sensitive data with the query!