## 4 Authentication Microservice  
The authentication mechanism, in the case of legacy applications, is based on the server, which _keeps the secrets_ and, when it is queried, the provided credentials are validated, and the access authorization is provided. The server keeps track of login and session information in order to prevent relevant cybersecurity problems, such as the replay attack. Often based on the clients' needs, the provided tokens are stored during their working sessions (e.g., as cookies). The microservice authentication process implements different mechanisms due to their distribution and asynchronous model of action. A widespread method that is used for authentication is JSON Web Token (JWT). The method enables the delegation of authentication to external services in a stateless and space-efficient manner [61]. JWT implements other standards, such as JSON Web Signature (JWS) or JSON Web Encryption (JWE), for message authentication and encryption. A JWT consists of three parts: header, payload, and signature. Let us note the example provided in the RFC specification and listed in Table 1. The header section indicates that the media type is _application/jwt_ and specifies the algorithm used for digitally signing the token, in this case, HMAC SHA-256. The payload section is used for storing the claims. Claim Names are case-sensitive and have to be unique. Otherwise, applications can reject the JWT or use the lexical last claim name as a fallback. For interoperability purposes, some names are registered in the IANA _JSON Web Token Claims_ registry. These include the issuing entity (_iss_), the issue date and time (_iat_), as well as \begin{table}
\begin{tabular}{l l} \hline \hline
**Section** & **Payload** \\ \hline Header & [“type”:JWT”, “alg”:“HS256”] \\ Payload & [“iss”:“hpc”, “exp”:167244800, “[[http://cs.unitbv.ro/is](http://cs.unitbv.ro/is)]([http://cs.unitbv.ro/is](http://cs.unitbv.ro/is))\_root”:true] \\ Signature & Iuu5x6 ttPU5 at/Nkxme4V6 ffWUWZmTl0 bX0 EimXYxo \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Anatomy of a JWT. Figure 11: Access the web service getmeasurement. Figure 12: Access the web service endpoint using an HTTP GET parameter. the expiration date (_exp_). The last claim from the payload section in Table 1 represents a custom claim, which signifies that the user successfully authenticated as an administrator on the specified domain, and services can use it for authorization purposes. To build a complete JWT, the contents of the different sections will be encoded with base64 url and concatenated with separating dots (Table 2). According to the specification, the JWT implementations only have to include the signature algorithms HMAC SHA-256, the other fields being optional. Considering an application that implements microservices-based distributed architectures, a microservice could handle the login process and provide a JWT that would be stored on the client side. The validity of the JWT could then be checked either on the API Gateway or by each microservice that receives a request. When connecting to the user interface, the application detects that the user possesses no valid authentication token and redirects them to the login page. After entering the credentials, a request is sent to the _/user/login_ path, which contains the email and password in the form of JSON records. The ingress controller identifies all URLs starting with _/user_ as belonging to the authentication service and consequently routes them accordingly. The authentication service checks the credentials against the ones stored in the directory (or database), and if valid, it issues a pair of authentication and refresh tokens. Using the valid tokens, the user is considered to be logged into the whole application and can use the other microservices (Figure 13). Firstly, the user is forwarded to a dashboard application, where they can access the other functionalities using the specific menu and options.