*3.2. Quality Factors*

We have done a verification to understand if there is any kind of relationship between the quality score and the year the study was published. Although it is possible to verify that the average score increased over the years, the standard deviation and the coefficient of variation show that the data are heterogeneous, and it is not possible to conclude that the quality has increased over the period, as shown in the Table 3. It is possible to verify in this situation that the standard deviation increases in the same proportion as the average, in addition to the coefficient of variation being in a high degree.

**Table 3.** Average study quality score by year.


We performed analyzes on data extracted from selected studies to answer the research questions.

#### *3.3. RQ.1. What Are the Challenges Mentioned in the Literature to Perform Authentication and Authorization in the Context of Microservice Architecture Systems?*

The challenges identified about authentication and authorization in the context of microservice architecture systems are presented in Table 4. Such challenges were presented according to the number of mentions in the selected studies, therefore, it does not mean that these are the most critical in terms of vulnerabilities or how much they occur in a microservices environment. The number of mentions of the challenges found in the studies does not necessarily reflect a level of priority in which they should be observed

in a practical environment. Among the identified challenges, the five most mentioned in the literature were: "Communication between microservices" (13 mentions), "Trust between microservices compromised by unauthorized access" (12 mentions), "Individual concern for each microservice" (12 mentions), "Increased attack surface" (12 mentions), and "Microservice Access Control" (10 mentions).

**Table 4.** Challenges related to authentication and authorization in microservices


In general, the studies that mentioned the existing challenges made comparisons between monolithic and microservices architectures, explaining that in the monolithic model, there is only one surface to be protected, however, in the microservice environment, each autonomous service must be a point of concern regarding security, making it more

complex to keep this entire ecosystem properly protected. Although each service needs particular attention, Yarygina and Bagge [7] alerted that manual security provisioning of hundreds or thousands of service instances is infeasible. Pereira-Vale et al. [4] compared monolithic with microservices using a KLOC metric (kilo Lines of Code), they say that in a monolithic application, every 100 kloc will have an average of 39 vulnerabilities. The same quantity of lines of code in a microservice application, will have an average of 180 vulnerabilities. They also alert about the decomposition of monolithic into microservices because security needs to be a global property, not the sum of local security defenses.

Nehme et al. [27] argue the importance of authentication and authorization in the context of microservice security. They mentioned that "Microservices should only be invoked after requesting authentication and, ideally, authorization if levels of privileges are available.". Pereira-Vale et al. [28] performed a systematic mapping about security mechanisms used in microservices and they discovered that the most reported security mechanisms are related to authorization, authentication and credentials. Banat et al. [29] also agreed that authentication and authorization need to be carefully observed in a microservice architecture, because this scenario presents many points of access for users and the other parts of the application. They argued that the data being especially sensitive, the crucial point of the development is the authentication and the authorization process. Cao et al. [33] proposed the implementation of a global authentication and authorization mechanism named Unified Account Management as a Service (UAMS). In this implementation, they used a RESTful API divided into several microservices. All sensitive data is transferred encrypted by the HTTPS protocol.

The studies also highlighted that microservices have the characteristic of communicating with each other, usually through the HTTP protocol, and this is a point of attention that differs from the traditional monolithic approach and should be properly analyzed and observed in terms of security. Regarding the communication issue, the authors mentioned the implementation of Transport Layer Security (TLS), used to protect the communication channels [30].

The challenges presented, in general, complement each other, or even act transversally. Mateus-Coelho et al. [3] stated that "Microservices are often designed to trust their peers and, if one of them is compromised and accessed improperly, it is possible that there is a grea<sup>t</sup> advantage for all others to be exploited". Dongjin et al. [25] agreed when they affirmed that "When a single service is controlled by an attacker, the service may maliciously influence other services". Nehme et al. [31] mentioned an access control problem that may be found in microservice architecture named "confused deputy attack", in their words, it is a privilege escalation attack in which a microservice that is trusted by other microservices is compromised. Sun et al. [9] brought the concern about trust between services, they affirmed that the "compromise of a single microservice may bring down the entire application". They also reported the challenge of monitoring and auditing the microservices interaction over the network and proposed a design of a security-as-service infrastructure for microservices-based cloud applications, that helps to monitor the network aiming to find possible non-expected behaviors in the communication between them.

Pereira-Vale et al. [4] stated that the communication between microservices is exposed through the network environment, which creates a potential attack surface. The authors also mentioned the problem of increasing the attack surface, as the decomposition of an application into several services increases the attack surface and the security of the application becomes more difficult to manage, because it becomes the sum of several independent defenses, rather than being managed in a global way, as was done in the monolithic approach.

Nguyen and Baker [24] warned that network communication between microservices can occur in the internet environment, which increases, in addition to exposure, the number of possible attackers. Kramer et al. [16] reinforce this concern to implement secure application in smart city clouds using microservices, because it will handle with a huge amount of data, including sensitive information about infrastructure and citizens. Xu et al. [15]

shared the same concerned, in this case, using microservice in IoT devices. Lu et al. [34] is also concerned about security in IoT devices using microservices architecture, mainly because of sensitive data that can be shared among services. They encourage the use of API gateways, that will remove all the concerns about microservices, because all interactions with the components will be performed with the API Gateway. Safaryan et al. [21] are also concerned about communication among different microservices because it is carried out through network interaction, being necessary to secure each of the service and the network. They also alert about the need of a pattern to be implemented. The lack of a correct pattern can compromise the network environment. Nguyen and Baker [24] agreed about the need to observe communication between the services. Banati et al. [29] argued that the network used in microservices communication can be secured using system administration tools such as VPN, Firewall and HTTPS.

Dongjin et al. [25] and Jander et al. [30] raised a concern that if a single service were controlled by an attacker, it could maliciously influence all other services. Concerns related to communication between microservices, increased surface exposure, access control and individual concern in each microservice, the API Gateway strategy, and use of mechanisms such as OAuth 2.0 and JWT were widely mentioned. They are also concerned about the industry, which are not fully aware about security issues involving microservices.

API Gateway helps to limit exposure between microservices as requests will be centered on it, and no longer on a microservice directly [3,8]. Jin et al. [23] mention that API gateway will secure a microservices environment because it will filter all requests. They also proposed an edge gateway to manage microservices. Nehme et al. [27] not recommended the access token validation in the gateway level, this role need to be performed in an authentication server. In contrast, Torkura et al. [37] proposed a security gateway used as security control for enforcing security policies. They also alerted about discoverability, that means, a gateway feature that allows a microservice to subscribe in it. If the discovery service can accept any subscription, vulnerable microservices could be pushed to production environments. OAuth 2.0 is a popular authorization protocol and could protect access to microservices from unauthorized access as access tokens are issued to trusted clients that could access certain services [25]. Nguyen and Baker [24] explained that OAuth 2.0 is not only used in web-based application but can be applied into backend services with no need of web browser or user interaction. ShuLin and JiePing [22] mentioned that the JWT is an open standard (RFC 7519) that defines a compact and independent way to securely transmit information between parties as a JSON object. This information can be verified and trusted because it is digitally signed.

Barabanov and Makrushin [8] warned that implementing authorization directly in the source code of each microservice can lead to future problems, especially in different teams working on independent microservices, because of new security updates must be performed in all projects, individually. He and Yang [36] followed in the same line, they alerted that imitate the way of monolithic structure in each microservice has several deficiencies, mainly when a new service join in the system, it will be necessary to implement the security function in this case. They proposed a solution creating a specific service focused on authentication and authorization, as a result, each service is focused on its own business, ensuring better scalability and decoupling the system.

Jander et al. [30] mentioned that different teams can implement their own internal security approach in the microservice which they have responsibility for, but this may require more specialized knowledge from the teams. Torkura et al. [37] brought the concern that development by different teams can bring microservices using not only different standards in development, but also different technologies, which must implement the same security standards.

Lu et al. [34] stated that the development of microservices by different teams and even different companies is completely possible, is there is an alignment on the security implementations in each microservice. Finally, it is important to mention that the lack of security patterns in microservices, added to the few studies on the subject, both theoret-

ical and practical, can influence the managemen<sup>t</sup> of the development of the architecture. Torkura et al. [37] warned that there are several literatures that highlight security problems in microservice architectures, however, none of them offer practical solutions to deal with these situations.

Pereira-Vale et al. [4] alerted about the use of an authentication and authorization service to be used in an architecture of microservices. The use of this server must be robust enough to authenticate the user and carry out the token validations that are made with each client request. The lack of concern about these challenges can cause a single point of failure of failure (SPOF), that is, if this part of system fails, will affect the entire application [38]. ShuLin and JiePing [22] stated that the authentication server may affect the performance of the entire system, mainly if there are several requests to this server.

Preuveneers and Joosen [35] alerted about the flow of the data among microservices. Even if each individual microservice is protected, it is important to note if the workflow is valid. In that work, they presented a workflow-oriented framework to avoid not expected communication between microservices.

Mateus-Coelho et al. [3] enumerated some examples of mechanisms which must be observed during the developing in a microservice architecture: complex passwords, authentication, web security flaws (what are the most flaws observed), people and processes. They also listed the most critical web application security risks: injection, broken authentication and session management, cross-site scripting, broken access control, security misconfiguration, sensitive data exposure, insufficient attack protection, cross-site request forgery, components with known vulnerabilities and under protected APIs. All of them may be exploited in a microservice environment. Nguyen and Baker [24] also pointed some web security risks and carried out some experiments using CSRF attack, XSS attack and Brute Force attack in an API endpoint protected by OAuth 2.0. In this case, all of tests were prevented by the configuration proposed in the Proof of Concept presented in that work.

#### *3.4. RQ.2. What Mechanisms Are Used in the Literature to Deal with the Challenges Related to Authentication and Authorization in a Microservices Architecture?*

The mechanisms identified in the literature used to deal with authentication and authorization challenges in microservices architecture are presented in Table 5. The OAuth 2.0 protocol was the most mentioned (16 mentions), followed by JWT (14 mentions), API Gateway (14 mentions), Single Sign-ON (8 mentions) and OpenID Connect (7 mentions). Figure 3 shows the number of occurrences of the mechanisms used in the selected studies. Some mechanisms were used in only one study. It is important to emphasize that, in general terms, the identified mechanisms do not need to be implemented in a unique way, that is, they can coexist in the same environment, each one acting with a specific purpose. We identified in the selected studies some implementations in which the mechanisms act together, to mitigate possible vulnerabilities involving authentication and authorization in the microservices environment. It important to observe that some studies only point the mechanisms without explain deeply or demonstrate a practical implementation of them, such as the work of Pereira-Vale et al. [28], which is more concerned in perform a systematic mapping of security mechanisms.


**Table 5.** Security mechanisms used in microservices architecture

We will present a brief description of the most mentioned mechanisms in the selected studies:

•**OAuth 2.0 (Open Authorization):** The OAuth 2.0 protocol is defined by RFC 6749 [39]. According to Banati et al. [29] OAuth 2.0 is an authorization framework that allows users to access different services without having to share their credentials. In a practical scenario, the user authenticates to an authorization server and receives an authorization code or an access token, which can be used to access resources, without the need to contact the authorization server again or have to inform the username and password [25]. Access tokens are validated on each request for some service [15,35]. This procedure poses a risk for affecting the performance of a distributed architecture because if there is a large number of requests, the authentication server may be affected [22]. OAuth 2.0 is one of the protocols most used by microservice architectures for access delegation [25,31] and can be applied both in web applications and in backend services, in addition to meeting both the authentication and authorization proposal [24,28]. It is important to mention that OAuth 2.0 is widely used as an authorization protocol to protect services that use the REST (Representational State

• Transfer) [23,25,27], in addition to adopting the HTTPS protocol in data communication [25].

	- **API Gateway**: In the microservices environment, API Gateway acts as an intermediary between the client and the microservices, providing a private network environment that allows the exchange of private data [3,15], that is, clients do not communicate directly with services, but only with a Gateway, which is responsible for communicates with the requested service. It can be an input that performs the filtering of client requests, making the appropriate forwarding to the microservice [23], and it can check the user's credentials, to find out if he owns the proper authorization [7,37]. We realized that API Gateway is a technique to decrease microservice exposure. Nevertheless, it is important in a future work compares the communication in different scenarios. These scenarios could be using or not using the API gateway between the client and microservices. Consequently, it will be possible to collect the strengths and weakness of both approaches and verify the possibility of hybrid scenarios.

Lu et al. [34], stated that the API Gateway can aggregate multiple microservices in a single client interface, being an element that stands between the client and the requested service. Using the API Gateway helps to reduce the exposure of systems, then, the microservices are all protected behind the API Gateway [8]. Although several advantages for its implementation have been observed, its use may not prove advantageous when it becomes a single decision point, because, in case of failure in this element, the entire application may become inaccessible [8]. An API Gateway can use services such as JWT and OAuth 2.0 [7,8,15,23,25,34,36].


Banati et al. [29], the main purpose of this mechanism is the exchange of authorization credentials and not the authentication by itself. The authors also reinforced that the mechanism guarantees unified authentication in microservices and the implementation of this feature can improve the user experience [33]. In the same way as the API Gateway, the implementation of an SSO server may cause a "Single Point of Failure", that is, if there are problems in this system, every application can be compromised, as it centralizes all authentication of a system [36]. It is possible to implement a Single Sign-On system based on OAuth 2.0 [16,29,35].


**Figure 3.** Number of occurrences versus security mechanisms found

#### *3.5. RQ.3.What Are the Main Open-Source Technology Solutions That Implement the Authentication and Authorization Mechanisms Identified in the Literature?*

The main open-source solutions that implement the authentication and authorization mechanisms identified in the literature are presented in Table 6. It is possible to notice that the Spring [46] ecosystem libraries are the most mentioned (Spring Security, Spring Cloud, Spring Boot, Gateway Zuul and Eureka Server), totaling 10 mentions. We realized that Spring Boot and Eureka are not focused on security, but they have specific security libraries that can be used together. For instance, implementing Spring Boot allows to implement Spring Security library, and Eureka helps to implement an API Gateway using Spring Cloud. Some of these studies demonstrated a practical implementation of Spring framework using security mechanisms [21,22,24,25].

Although the research found several references to the Spring ecosystem, which is built by Java programming language, it is important to mention that there are alternative frameworks based in other languages that implement the security mechanisms found into a microservice environment, such as GoKit (Golang) [47], Flask (Python) [48] and .NET Core (C#) [49].

The other open-source solution mentioned more than once is called Kong [50] (2 mentions), the others being mentioned only once. It is important to note that the Spring Framework uses the Java programming language and has several libraries for implementing security mechanisms in microservices, such as API Gateway, OAuth 2.0 and OpenID Connect [46]. The Kong application refers to the "Kong API Gateway", that is, among all the mechanisms raised, it supports the implementation of an API Gateway.


**Table 6.** Open-source technologies that implement security in microservices architecture.
