Authentication and Authorization in Microservices Architecture: A Systematic Literature Review

: The microservice architectural style splits an application into small services, which are implemented independently, with their own deployment unit. This architecture can bring beneﬁts, nevertheless, it also poses challenges, especially about security aspects. In this case, there are several microservices within a single system, it represents an increase in the exposure of the safety surface, unlike the monolithic style, there are several applications running independently and must be secured individually. In this architecture, microservices communicate with each other, sometimes in a trust relationship. In this way, unauthorized access to a speciﬁc microservice could compromise an entire system. Therefore, it brings a need to explore knowledge about issues of security in microservices, especially in aspects of authentication and authorization. In this work, a Systematic Literature Review is carried out to answer questions on this subject, involving aspects of the challenges, mechanisms and technologies that deal with authentication and authorization in microservices. It was found that there are few studies dealing with the subject, especially in practical order, however, there is a consensus that communication between microservices, mainly due to its individual and trustworthy characteristics, is a concern to be considered. To face the problems, mechanisms such as OAuth 2.0, OpenID Connect, API Gateway and JWT are used. Finally, it was found that there are few open-source technologies that implement the researched mechanisms, with some mentions of the Spring Framework.


Introduction
The microservice architectural style is represented by an ecosystem of small services, each running in its own process and communicating through lightweight protocols, such as HTTP (Hypertext Transfer Protocol), built around business resources and deployed independently [1]. Breaking an application into microservices can bring some benefits, such as optimizing management, scalability, availability and reliability [2,3]. However, it may bring challenges in relation to security, because, in this case, an individual attention about it must be observed in each microservice developed, different from the monolithic style where security strategies are applied in a single application [3,4]. Furthermore, there are few practical demonstrations in the literature describing solutions to improve the security of [4] service-oriented architectures.
Regardless of the implemented architecture, the authentication and authorization aspects are relevant, considering them as key elements for the security mechanisms [5]. Authentication is the process of determining whether someone or something is, in fact, who they claim to be. Authorization is the process of giving someone or something permission to do or possess something [6]. There are protocols that deal with authorization and authentication issues, such as OAuth 2.0, the standard for delegated authorization, and OpenID Connect, the authentication layer on top of OAuth 2.0 [7]. It is important to note that there is a distinction between user authentication and service authentication. In the case of authentication between microservices, there are specific mechanisms for this, such as Mutual Transport Layer Security (MTLS) [7]. Using MTLS, each microservice will legitimately identify who it talks to, while also ensures data confidentiality and integrity in this communication [8].
According to some studies, microservices are usually designed in such way that there is a relationship of trust between them [3,9]. However, it is possible to find microservice architectures that use the "zero-trust" paradigm [10]. In this last case, there is a premise that trust is never granted implicitly but must be continually evaluated [11]. Thus, a lack of observation about authentication and authorization in a single microservice can affect the entire ecosystem. It is important that studies related to security issues in microservices emphasize aspects involving authentication and authorization. Therefore, in this paper, we carried out a Systematic Literature Review (SLR) to identify in the literature the studies that address authentication and authorization in microservice environments, what are their challenges, security mechanisms used to deal with these challenges and open-source technologies that implement the mechanisms identified in the review. The focus on opensource is to provide technologies that can reduce costs, free access to source code and customization [12]. There are advantages for use open-source in the public sector, such as avoiding monopoly dominance in the market [12]. Last, but not least, even software developed by commercial firms is being released under open-source licenses as well [13]. It is important to note that the adoption of open-source, although it has the advantage of free use, it will not necessarily bring an adequate cost/benefit for the organization [14]. Therefore, it is recommended that its adoption be based on metrics such as the Total Cost of Ownership (TCO), an instrument that assesses the cost of adapting, managing and maintaining the proposed software [14].
Our main findings reveal that authentication and authorization challenges involving microservices are mostly related to the communication between them and the complexity of implementing security in each microservice, generating a complexity both in the development and in the increase of the attack surface, since individual attention must be given to each microservice. The most mentioned mechanisms in the literature that address the challenges of authentication and authorization in microservices are OAuth 2.0, JWT, API Gateway and OpenID Connect, in addition to Single Sign-on strategy. These mechanisms can be implemented together, with their respective role in the security context. The API Gateway acts as an intermediary between the external client and the microservices, providing a private network environment that allows the exchange of data between them [15]. Single Sign On (SSO) allows users to authenticate only once and use all apps associated with their user accounts, without requiring them to enter their credentials each time they access a different app [16]. Finally, we identified that the Spring Framework is widely used in the context of open-source applications.

Systematic Literature Review
To achieve the research goal, we performed a Systematic Literature Review (RSL), in accordance with the guidelines proposed by Kitchenham and Charles [17] and the structuring applied by Kitchenham et al. [18]. According to the authors, an RSL is "a means of identifying, evaluating and interpreting all available research relevant to a specific research question, or topic area, or phenomenon of interest" [17]. In addition, we used the online tool Parsifal [19] to support the screening and analysis of the identified studies.

Research Questions
We conducted the SLR to answer the following research questions (RQ):

Search Process
To identify studies in the literature, we performed an automatic search in the main digital databases in the field of Computer Science. The digital databases used in the systematic literature review were: DBLP (https://dblp.uni-trier.de, accessed on 4 February 2022), IEEE Digital Library (http://ieeexplore.ieee.org, accessed on 4 February 2022) and Scopus (http://www.scopus.com, accessed on 4 February 2022). The search string used in digital databases was defined according to the keywords that must appear in the search results. The search string used was: ("MICROSERVICE" OR "MICROSERVICES") AND ("SECURITY" AND "AU-THENTICATION" AND "AUTHORIZATION") AND ("CHALLENGE*" OR "PROBLEM*" OR "ISSUE*" OR "SOLUTION*" OR "PROTOCOL*" OR "MECH-ANISM*" "STRATEG*" OR "IMPLEMENTATION*" OR "OPENSOURCE" OR "OPEN-SOURCE" OR "OPEN SOURCE").
We also applied the "snowballing" process which aims to prevent relevant studies from being omitted [20]. In this process, references about the research object in each selected study are verified. Thus, we searched for papers where selected studies were cited.

Inclusion and Exclusion Criteria
The selection criteria for primary studies seek to identify papers that provide information about the research questions. Therefore, we defined the following inclusion and exclusion criteria, based on the research questions: Inclusion Criteria

Quality Assessment
To differentiate selected studies according to quality criteria we check in each selected study whether they answer the research questions. The criteria adopted were:

1.
Is the research objective clearly described? 2.
Do the authors describe the limitation of the study? 3.
Does the study identify problems and/or challenges involving authentication and authorization in microservices architecture? 4.
Does the study identify the mechanisms that mitigate the problems and/or challenges involving authentication and authorization in microservices architecture? 5.
Does the study present solutions that implement security mechanisms using opensource technology?
The answer of each quality criterion question received a score, as follows: 1. Yes (1); 2.
Although the primary studies were selected using specific criteria, there is an individual assessment of the quality for each study, to verify which of them are more aligned with the research questions that were defined.

Data Collection and Analysis
The following data were collected in the selected primary studies: (1) Authentication and/or authorization challenges found in microservices; (2) The mechanisms that deal with the authentication and/or authorization challenges found in microservices; (3) Open-source technologies that implement mechanisms which deal with authentication and authorization challenges in microservices.
The identified challenges, mechanisms and solutions were organized in a ranking to verify the most mentioned in the primary studies. This ranking aims to show what manuscripts have more answers about the research questions, this does not mean that the lowest rated manuscripts are worse than the first ones, it just means that the top-rated manuscripts have more information to answer our questions. Subsequently, the items most present in the studies were submitted to an individual analysis for a better understanding of their basic concepts. Finally, it was verified which specific mechanisms deal with the challenges found.

SLR Results
This section presents the results of performing the systematic literature review. Figure 1 shows the complete execution process of the proposed protocol to execute the SLR, with the respective quantity of studies identified in each step of the protocol. In the automatic search performed in the digital databases using the initial query, 22 papers were found. These studies were submitted to the snowballing process, resulting in 13 new selected papers. Of the 22 papers found initially, 11 were eliminated due to the exclusion criteria (5 studies that do not address the research object and 6 duplicate). Thus, 11 primary studies were selected from the digital databases and 13 studies on snowballing execution, totaling 24 primary studies. The selected primary studies are shown in Table 1. The filters applied during the SLR based on inclusion and inclusion criteria are demonstrated in Figure 2.

Quality Assessment of Reviews Carried out
According to the quality criteria, the selected studies were analyzed and scored, as shown in Table 2. All primary studies mentioned challenges involving authorization and authentication in microservices (AQ3), as well as mechanisms to mitigate such problems (AQ4), even if partially. However, there is a smaller amount of work (15) mentioning open-source technologies that implement the mechanism (AQ5). In general, the studies are clear about the objective (AQ1), but 11 of them do not describe its limitations (AQ2).

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. We performed analyzes on data extracted from selected studies to answer the research questions. 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 Communication between microservices S1, S2, S3, S4, S7, S9, S10, S15, S16, S17, S18, S23, S24 13 2nd Trust between microservices compromised by unauthorized access S1, S2, S4, S6, S8, S12, S15, S16, S19, S21, S23, S24 12 3rd Individual concern for each microservice S1, S2, S5, S10, S12, S13, S15, S16, S21, S22, S23, S24 12 4th Increased attack surface (compared to monolithic) S1, S2, S3, S7, S8, S13, S14, S16, S17, S23 10 5th Microservice access control S5, S8, S10, S11, S14, S15, S19, S20, S21 9 6th Authorization between services S1, S7, S8, S15, S16, S17, S18, S21 8 7th Lack of studies about microservices S1, S2, S4, S8, S10, S13, S17 7 8th Lack of security patterns in microservices S1, S13, S15, S17, S20, S21 6 9th Different teams working on different microservices must have the same understanding of security S3, S15, S17, S20, S23 5 10th Bypass on Api Gateway S3, S4, S6, S12 4 11th Intrusion detection/monitoring S1, S12, S24 3 12th Escalation of privileges S2, S16, S24 3 13th Lack of study demonstrating practical implementation of security in microservices S7, S13, S23 3 14th Coordinate authentication server with new microservices S1, S22 2 15th Lack of attention in attack reaction/recovery S1, S13 2 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 great 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 management 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.
In addition to user information, it is common to find in a JWT their permissions and expiration time of the token [36]. The JWT has adherence to "stateless" applications, that is, those that do not keep a session on the server side, but stay data with the client side, and must be used in each client request to the resource [26]. In a microservices environment, JWTs can be transferred during the communication between them [35]. Finally, it is important to know that JWT can be integrated with the OAuth 2.0 protocol [4,23]. • 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]. • OpenID Connect: OpenID Connect is an open authentication standard that ensures users have only one digital identity for multiple applications or services [29]. Dongjin et al. [25] stated that it is an authentication layer over the OAuth protocol, allowing services to read the user's basic information. Nehme et al. [27,31] observed that OpenID Connect is built on top of the OAuth protocol. Yarygina and Bage [7] reinforced that OpenID Connect provisions the user's identity. OpenID Connect can be used in conjunction with OAuth 2.0 [4,8,35]. There is a difference between OpenID and OpenID Connect (OIDC). According to the OpenID Foundation website, "OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly, and usable by native and mobile applications" [41]. They also explain that "OpenID Connect defines optional mechanisms for robust signing and encryption. Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself" [41]. • SSO (Single Sign-On): SSO allows a user to be authenticated only once when logging into a particular system, therefore, users can access all authorized resources and services on a system without needing another authentication [29,36]. According to 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]. • HTTPS: The Hyper Text Transfer Protocol Secure is defined by RFC 2818 [42]. It describes the use of HTTP over TLS (Transport Layer Security). Using the HTTPS protocol will ensure that the communication be encrypted [16]. It provides a channel between two hosts identified by certificates [30]. The use of HTTPS not just limited to encrypt data, but ensures that a given client is communication with whom he wants to [3]. • RBAC: Role-Based Access Control is used in authorization process [4]. It is a very know identity-based access control model [35]. The use of a role-based access control will increase the flexibility of the system because the role will define what access the client is allowed [22]. RBAC is user-centric access control model, it does not account for relationship between the requesting entity and the resource [7]. RBAC authorization roles can be incorporated into JWT tokens as an additional attribute [7]. • ABAC: Attribute-Based Access Control, based in the words of Preuveneers and Joosen [35] "grants access rights to subjects through the use of policies or rules that combine various types of attributes to facilitate user access to the right resources under the right conditions". They complemented that it offers more expressivity and flexibility compared to another access control models such as RBAC. The primary goal of ABAC in the words of Yu et al. [25] is "an access control model is to fulfill the requirements of highly heterogeneous environments such as multi-cloud environment". They also pointed the benefit of centralized security management and orchestration that will protect the application according to consistent policies. ABAC is recommended to be used when there is fine-grained authorization of resources, such as access to a specific API call [7]. • XACML: eXtensible Access Control Markup Language is defined by RFC 7061 [43]. According to this document, XACML "defines an architecture and a language for access control (authorization). The language consists of requests, responses, and policies". It is used to create access control policies and can be used with OAuth 2.0 protocol [31]. Nehme et al. [31] proposed a model using XACML along with OAuth 2.0. In this case, OAuth 2.0 acts as an authorization service and XACML with policy administration and decision points. Barabanov [44]. In the words of Mateus-Coelho et al., HMAC consists in "hash-based messaging code to sign the request". According to the same authors, there are many examples that can be found in internet suggesting the use of HMAC over HTTP. HMAC algorithm can also be used to sign a JWT [22]. • SAML: The Security Assertion Markup Language (SAML) 2.0 is defined by RFC 7522 and is defined as an XML-based framework that allows identity and security information to be shared across security domains [45]. In a microservices environment, SAML is used to exchange user attributes stored at the identity provider [35]. Mateus-Coelho et al. [3] affirmed that "SAML and OpenID is perfect for Authentication and Authorization of someone's on a system but it's also great for service-to-service authentication as well". Nevertheless, they admitted that SAML is complex when it is compared to other technologies such as Api Keys. protocol to protect services that use the REST (Representational State Transfer) [23,25, 362 27], in addition to adopting the HTTPS protocol in data communication [25].

JWT (JSON Web Token):
The JWT is defined by RFC 7519 [40]. It is an open standard 364 that provides a compact and independent way to securely transmit information be-365 tween applications using a JSON (Javascript Object Notation) object. This information 366 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.

Discussions
Given the challenges, mechanisms and open-source solutions presented, it was verified which of the mechanisms and solutions could be implemented to face the challenges, according to what was collected in this RSL. Table 7 presents the solutions that act on the related challenges. It was verified that part of the challenges does not have a direct link on the open-source mechanism and/or implementation. The mechanisms identified could be applied to face 09 challenges of the 20 listed in Table 4. Although it seems a low number, these challenges are the most mentioned by the authors.
The mechanisms were widely mentioned by the authors, most of them can face the challenges, with emphasis once again on the implementation of OAuth 2.0, JWT, API Gateway, OpenID Connect and Single Sign ON (SSO). Nevertheless, it does not mean that they are better or will solve any kind of security issues related to microservices architecture. Even the less mentioned mechanisms could be more appropriate, depending on the case. It is important to know what each mechanism is individually and what it does, for then, implement a good security architecture in a system.

Study Limitations
The study was performed with searches in DBLP, IEEE and Scopus databases. To prevent relevant works from being discarded, the snowballing process was applied. Even with this concern, it is possible that, increasing the number of databases for consultations, new studies may be found. However, as verified in some studies collected, there is currently a lack of studies on the subject [3,4,7,16,21,25,28]. It was also verified that there is a lack of studies demonstrating the practical implementation of security in microservices [24,28,37]. Hence, it is likely that over the next few years, if the research related to the subject in question increases, a new systematic review will be necessary, in order to complement the knowledge collected in this work. We cannot conclude that the mechanisms less mentioned in the studies are less used, therefore, it is important to explore all of them, that can be done in a future work. Finally, it is important to note that this study is more focused on identifying answers to the research questions, that is, it is possible that the answers to these questions may be the subject of further studies pointing out which challenges are most critical in terms of vulnerability, how much they occur in a practical environment, or even which of these challenges should be addressed with priority. The mechanisms can also be implemented and tested in order to find out in a practical environment which of the challenges are mitigated with the implemented mechanism.

Final Remarks
As verified during the execution of this work and demonstrated in Table 4, there is a lack of studies related to security in microservices architecture. The lack increases when the study is specific for authentication and authorization, especially in a practical approach. It is important that the subject be better explored, because, as verified in this work, within a microservice environment, it is necessary to be concerned with security aspects in each service, individually, as the adoption of this architecture can increase the attack surface and still generate attention points in the communication between them, in this way, the lack of attention in these questions can make the applications vulnerable to unauthorized accesses. Of all the points listed in Table 4, there are issues related to the implementation of technologies themselves, however, there are other aspects related to the subject, such as the organization of development teams working on different microservices within the same system, therefore, is a theme with vast field to be explored.
Several mechanisms were found that mitigate the main points of attention observed, all of them listed in Table 5, with OAuth 2.0 being the most mentioned, along with the Json Web Token (JWT) and the use of API Gateway. The correct implementation of these can reduce the possibility of any type of unauthorized access to one or more microservices, making the environment better protected. There are few studies on practical implementations, thus, a scenario for future work is foreseen, especially with proposals for specific patterns within this context.
Finally, it was found that the literature indicates few open-source solutions that implement the mechanisms found. In this case, a viable alternative expands the search into new sources, including gray literature, which is literature produced at all levels of government, academic, business and industrial, in print and electronic formats, but which is not controlled by commercial publishers, that is, where publication is not the primary activity of the producing body [51]. Such findings can be properly experimented with scientific rigor and identified as technical solutions that solve the challenges collected in this work.