# Authentication and Authorization in Microservices Architecture: A Systematic Literature Review
## 3 SLR Results
### Quality Factors
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]. [PERSON] and [PERSON] [22] stated that the authentication server may affect the performance of the entire system, mainly if there are several requests to this server. [PERSON] and [PERSON] [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. [PERSON] 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. [PERSON] and [PERSON] [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. 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 [PERSON] et al. [28], which is more concerned in perform a systematic mapping of security mechanisms. 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 [PERSON] 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].