# Authentication and Authorization in Microservices Architecture: A Systematic Literature Review
## 3 SLR Results
### Quality Factors
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. [PERSON] 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; 36; 34]. * **OpenID Connect**: OpenID Connect is an open authentication standard that ensures users have only one digital identity for multiple applications or services [29]. [PERSON] et al. [25] stated that it is an authentication layer over the OAuth protocol, allowing services to read the user's basic information. [PERSON] et al. [27; 31] observed that OpenID Connect is built on top of the OAuth protocol. [PERSON] and [PERSON] [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 [PERSON] 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].