## 2 Architecture
### The API Gateway  
The Gateway API serves as the conduit for communication between the different software packages within the \(\mu\)Doc.tS information system. These software packages encompass both the back end of the system and the user applications, whether they be web-based or desktop-based, that will be created using the \(\mu\)Doc.tS SDK. These user applications will form the front end of the overall \(\mu\)Doc.tS system. To ensure secure communication, users' applications can only interact with the back end if they possess the appropriate client credentials. The Gateway API is safeguarded by an authorization server known as the Identity Server. For a visual representation of the Gateway API's architecture, please refer to Figure 2.  
The Gateway API, Ocelot [26, 27], is deployed using advanced technology. Ocelot, an open-source Gateway API, is developed in C and utilizes the.NET Core framework. With its capabilities, Ocelot enables seamless and efficient interconnection of services and micro-services within an information system. This technology is extensively employed in the implementation of service-oriented architecture systems and applications. The suitability of Ocelot for applications like \(\mu\)Doc.tS is outlined in [28], citing its advantageous features. Ocelot was also selected due to its seamless integration with the Identity Server [29], which serves as the Authentication/Authorization Server. This server ensures the security and proper utilization of both the Gateway API and back-end applications. The Identity Server is responsible for **authenticating** applications by confirming their identity through presented credentials, such as the Client Id and Client Secret. Valid credentials result in the issuance of an access token with a lifespan of 50 min and a Refresh Token in Bearer JWT token format with a lifespan of 8 h. The Refresh Token is used to renew the access token when it expires, and a new license of the application must be issued using the Client Id and Client Secret after the Refresh Token expires. **Authorization** is also handled by the Identity Server, defining the permissions that each application has in the services of \(\upmu\)DoctS. Each user has a certain number of permissions that define their permissions in the application, and the Identity Server issues authorization tokens containing the rights of applications to access the services of an information system. Figure 3 depicts the process through which the Gateway API and Identity Server handle certification requests from client applications. The client application initiates a token request to the Token endpoint of the Gateway API, including the Client Ids and Client Secrets of each application. Subsequently, the Gateway API re-directs the user's request to the Identity Server, as illustrated in Figure 3.  
If the request is made with the correct credentials, the Identity Server responds to the application's request in JSON format, containing the access token. Each token issued by the Identity Server is an encrypted JSON Web Token (JWT). Consequently, the resulting  
Figure 3: The API Gateway general architecture. Figure 2: The Ocelot architecture with Identity Server authorization. information system possesses an additional layer of security, as the internal components of the application and the tools it serves remain shielded from external attackers. When making data calls to the Gateway API, the user must include the JWT token in each request. Failure to do so results in the Gateway API withholding content and responding with an Unauthorized 401 error message. The aforementioned architecture facilitates the management and scalability of the uDoc.tS information system. Each segment of the back end operates autonomously and can be configured and operated independently from one another. This division of labor reduces the workload by enabling shared and separate execution of processes, thereby preventing the Gateway API from being overwhelmed by parallel requests.