Almost all applications nowadays are using APIs to fetch and store data. These endpoints are (hopefully) secured and require authentication to access the user’s data. A lot of these authentication methods require a token to be send alongside the original HTTP request, most likely in the HTTP header.

The token is mostly used to indicate that a user has been logged in, which will result in the backend identifying the user, checking its permissions in the database, and if everything matches accessing and delivering the requested resources.

What happens if there is no user authenticated, but data is still supposed to be available to the application? Without any authentication method, the endpoints are completely open — and (in theory) other services may access the information as well by sniffing the application’s HTTP traffic or decompiling the app itself. To avoid having the information completely in the open, an application token can be used to identify the authenticity of the application.

This increases our available tokens to two, which means we have to select which one is supposed to be injected into the HTTP request headers, which requires logic.

The Problem

Sometimes it’s a requirement to send an application-token for unauthorized requests, to make sure only users of the original application may access the API. This is supposed to make reverse engineering harder and thus protect the data. This requires some sort of management for the authentication tokens, either depending on endpoint (some endpoints require the app-token, some the user-token) or on a “highest authentication” layer (if user-token is available, send the user-token, otherwise the app-token).