AUTHENTIC TECHNIQUES OF AUTHENTICATION IN MICROSERVICES

Microservices is the catch word of the town nowadays. The microservices are small, autonomous services doing a single task, and performing it well. However various concerns such as security in microservices are not explored yet. This paper presents a comparison of the existing protocols such as 2-way SSL, HMAC, SAML, etc. used for authentication and authorization of the end users by the service providers. It also explores the concerns where they lack and presents a model implementing OpenID Connect. It presents a proper comparison to propose OpenID Connect to be best of the lot.


INTRODUCTION
The rudimentary approach for developing software has been the monolithic way. Monolithic approach is still good for small scale teams and projects, nevertheless once scalability, flexibility and other requirements like fast development, short time to market, wider team alliance, and so on becomes gradually critical to accomplish business competitiveness, monolithic halts being profitable. This is where the Microservices architecture comes to rescue. Microservices is responsible for an intensive, scoped and modular tactic for application design. Microservices are small, autonomous services that work together. [1] It can be well elaborated using keywords: 'Faster development and Speed to production'. Microservices are deceptively termed to be code of limited length. Conversely, microservices are a piece of code which performs a single task and performs it soundly. They are independent in failure i.e. failure of a single component does not force the entire system to breakdown at once. The term micro indicates the services to be lightweight and which cannot be further divided into sub tasks and performs one task solely with minimal dependency on other services. They are independently scalable as well. The most perplexing part of microservices is defining the granularity of the services.
Security in microservices is one of the least explored topics. This paper explores the various vulnerabilities in security and also presents the various methods deployed for providing authentication and authorization in microservi microservices depends on the idea of loose coupling and high The rudimentary approach for developing software has been the monolithic way. Monolithic approach is still good for small scale teams and projects, nevertheless once scalability, flexibility and other requirements like fast development, short t, wider team alliance, and so on becomes gradually critical to accomplish business competitiveness, monolithic halts being profitable. This is where the Microservices architecture comes to rescue. Microservices is modular tactic for application design. Microservices are small, autonomous It can be well elaborated using keywords: 'Faster development and Speed to production'. Microservices are deceptively termed to be code of limited ength. Conversely, microservices are a piece of code which performs a single task and performs it soundly. They are independent in failure i.e. failure of a single component does not force the entire system to breakdown at once. The term e services to be lightweight and which cannot be further divided into sub tasks and performs one task solely with minimal dependency on other services. They are independently scalable as well. The most perplexing part of ularity of the services.
Security in microservices is one of the least explored topics. This paper explores the various vulnerabilities in security and also presents the various methods deployed for providing authentication and authorization in microservices. Since microservices depends on the idea of loose coupling and high cohesion. They do not share any databases. If at all the any dependencies among the microservices they use light weight communication mediums to achieve it. The most common and widely used communication methodology today are the REST APIs. REST APIs are simple, stateless and lightweight protocol used for Representational State Transfer is stateless several traditional authentication and authorization techniques fail to suffice the purpose. Several protocols are being modulated for securing the REST APIs. However there isn't a standa securing microservices. This paper provides a crisp comparison of the several traditional and upcoming techniques for providing authentication as well as authorization in microservices. It also implements a model on the OAuth 2.0 and OpenID Connect techniques employed for the authentication and authorization in microservices.
The further sections of the paper is as follows: Section 2 briefs about the topics that gave motivation for this paper. Section 3 explains the various perspectives in security in microservices. Section 4 describes the various traditional proposed solution for authentication and authorization in microservices. Section 5 presents the implemented model of the paper presenting OAuth2.0 and OpenID Connect techniques. Section 6 provides a crisp comparison of the strengths and flaws of the developed techniques. Section 7 puts forth the accomplishments of the paper.

LITERATURE SURVEY
Microservices has become a hot topic in field of software development. Its efficiency is well demonstrated by big giants like: Amazon, Netflix, eBay, etc. The book cohesion. They do not share any databases. If at all there are any dependencies among the microservices they use light weight communication mediums to achieve it. The most common and widely used communication methodology today are the REST APIs. REST APIs are simple, stateless and lightweight protocol used for communication. As REST: Representational State Transfer is stateless several traditional authentication and authorization techniques fail to suffice the purpose. Several protocols are being modulated for securing the REST APIs. However there isn't a standard protocol for securing microservices. This paper provides a crisp comparison of the several traditional and upcoming techniques for providing authentication as well as authorization in microservices. It also implements a model on Connect techniques employed for the authentication and authorization in microservices.
The further sections of the paper is as follows: Section 2 briefs about the topics that gave motivation for this paper. Section 3 explains the various perspectives involved related to security in microservices. Section 4 describes the various traditional proposed solution for authentication and authorization in microservices. Section 5 presents the implemented model of the paper presenting OAuth2.0 and echniques. Section 6 provides a crisp comparison of the strengths and flaws of the developed techniques. Section 7 puts forth the accomplishments of the Microservices has become a hot topic in field of software development. Its efficiency is well demonstrated by big giants like: Amazon, Netflix, eBay, etc. The book [1] on

Research Article
This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. microservices can be well called the fundamental guide to developing microservices. It exposes the concepts related to data partition, service discovery, circuit breakers, etc. that are required to be kept in mind while developing microservices. Eric Evans [3] describes the methodology that is to be adapted for modularizing the domain. It highly encourages designing of applications on the tunes of "loose coupling and high cohesion".
Alshuqayran et.al. in their paper [2] identifies and presents various architectural challenges related to microservice systems. This paper emphasizes on the fact that security in microservices is the least explored topic while designing and developing the microservices. It diagrammatically ex that only about 9% of the research is carried on microservice security as compared to the other concerns. This motivates to deep dive into the arena of security for microservices. Security is a gigantic topic, and thus can't be covered in a single paper. This paper focuses on the authentication and authorization module of security in microservices. It attempts to formulate a standardized model for authentication and authorization in microservices.

Various Standpoints in Securing Microservices
Microservices are vulnerable to several security issues. The security of microservices can be visualized in a number of standpoints. They are as follows:

Safe development lifespan and Test Automation
The backbone strategy of the microservices is the pace of development. The microservice should be simplified and quick to develop, scale, alter, test and deploy. While developing microservices, the various security vulnerabilities must be considered right from planning and designing stage. This facilitates a robust microservices to withstand several outbreaks.

DevOps Security
Microservices have various deployment configurations, the widely adopted pattern is one service per host. The host is usually a container (e.g. Docker). The containers by default have no security employed. Thus making our services more vulnerable to attacks. The alternatives for secluding the containers and the granularity to which it must be secluded must be planned.

Application Security
This is mainly considered with the access control to the deployed microservices. The application as a whole is not exposed to the users. Only few microservices of an application gets direct exposure to external world. Hence the security concern can be converged only on such microservices. The challenge is to authenticate the consumer and permit the login context amongst the microservices, in a symmetric routine, thus consenting each microservice to approve the user.

Theoretical Background
This section takes into account the various tradition techniques that were employed for providing authentication and authorization among the services. It also pin features due to which these techniques do not suffice the requirements of microservices. 3343 microservices can be well called the fundamental guide to t exposes the concepts related to data partition, service discovery, circuit breakers, etc. that are required to be kept in mind while developing microservices.
describes the methodology that is to be adapted highly encourages designing of applications on the tunes of "loose coupling and high identifies and presents various architectural challenges related to microservice systems. This paper emphasizes on the fact that security in microservices is the least explored topic while designing and developing the microservices. It diagrammatically explains that only about 9% of the research is carried on microservice security as compared to the other concerns. This motivates to deep dive into the arena of security for microservices. Security is a gigantic topic, and thus can't be covered in a paper. This paper focuses on the authentication and authorization module of security in microservices. It attempts to formulate a standardized model for authentication and

Various Standpoints in Securing Microservices
roservices are vulnerable to several security issues. The security of microservices can be visualized in a number of

Safe development lifespan and Test Automation
The backbone strategy of the microservices is the pace of development. The microservice should be simplified and quick to develop, scale, alter, test and deploy. While developing microservices, the various security vulnerabilities must be considered right from planning and designing stage.
ust microservices to withstand several Microservices have various deployment configurations, the widely adopted pattern is one service per host. The host is usually a container (e.g. Docker). The containers by default ecurity employed. Thus making our services more vulnerable to attacks. The alternatives for secluding the containers and the granularity to which it must be secluded This is mainly considered with the access control of the users to the deployed microservices. The application as a whole is not exposed to the users. Only few microservices of an application gets direct exposure to external world. Hence the security concern can be converged only on such challenge is to authenticate the consumer and permit the login context amongst the microservices, in a symmetric routine, thus consenting each microservice to This section takes into account the various traditional techniques that were employed for providing authentication and authorization among the services. It also pin-points the features due to which these techniques do not suffice the

2-way SSL / TLS
SSL/TLS scheme is only used for authentication. Furthermore it requires server to store clients' certificate thus violating the stateless property of REST used for communication among the microservices.

HMAC Signing
HMAC signing is too used for authentication only. It also requires sharing of keys thus weakening the solution. For each request the MAC will differ. Thus requires the entire procedure to be executed every single time.

SAML
SAML is very efficient mechanism but with SOAP predecessor of REST APIs. Here the users log in into the Identity provider and obtain a SAML. It then uses this SAML with the service providers to access their services. T protocol only makes use of one representation i.e. XML. However in modern day Json etc. representation have gained wide popularity. Also once the identity provider sends an assertion it deletes it from its database. Hence the service provider has no means to reassure itself later if required.

Proposed Security
The microservice require a robust authentication and authorization mechanism as it is highly distributed in nature. The most widely accepted protocol is OAuth 2.0. However there is an upcoming protocol OpenID Connect for both authentication and authorization. Both these pr not require the server to maintain sessions. Thus withstanding the REST and microservices constraint of stateless servers. Furthermore they eliminate the time and labor required for creating accounts for every service to access secured resources. They also do not compromise the privacy of the users. The users are relieved of entering their private information for registering with the several applications. They can simply exchange tokens and get themselves validated by the services. This paper protocols, and presents a comparison among them. SSL/TLS scheme is only used for authentication. Furthermore it requires server to store clients' certificate thus violating the stateless property of REST used for communication among HMAC signing is too used for authentication only. It also requires sharing of keys thus weakening the solution. For each request the MAC will differ. Thus requires the entire executed every single time.
SAML is very efficient mechanism but with SOAP-a predecessor of REST APIs. Here the users log in into the Identity provider and obtain a SAML. It then uses this SAML with the service providers to access their services. This protocol only makes use of one representation i.e. XML. However in modern day Json etc. representation have gained wide popularity. Also once the identity provider sends an assertion it deletes it from its database. Hence the service ans to reassure itself later if required.
require a robust authentication and authorization mechanism as it is highly distributed in nature. The most widely accepted protocol is OAuth 2.0. However there is an upcoming protocol OpenID Connect for both authentication and authorization. Both these protocols does not require the server to maintain sessions. Thus withstanding the REST and microservices constraint of stateless servers. Furthermore they eliminate the time and labor required for creating accounts for every service to access secured es. They also do not compromise the privacy of the users. The users are relieved of entering their private information for registering with the several applications. They can simply exchange tokens and get themselves validated by the services. This paper implements both the protocols, and presents a comparison among them.

Problem
OAuth2.0 though a popular protocol, has a lot of controversies associated with it. The first and foremost it brings lack of anonymity. When one logs in via an authorization server it gives the application rights or authorization to view its personal details stored there. OAuth is safe only when implemented correctly. However it does guarantee that this process is full proof. It can lead to security attacks like phishing, where innocent users may be prompted by a look a like authorization server and asked to enter their credentials. Thus leading to severe crimes.
OAuth is not a substitute for login func developed to be used in scenarios where one requires to import its data from Website A to Website B. The very misconception in the use of OAuth2.0 is that it suffices both the needs of the application i.e. Authentication along with Authorization. It in fact does none. Furthermore even if OAuth relieves users from inflowing passwords for several websites it does not provide complete security. Because though the passwords won't be intercepted but in future if the Resource Owner gets compromised the authorization that one provides can be exploited. For e.g., if one allows a website A (resource owner) to post on the Facebook page with the use of OAuth, and in future Website A gets hacked. The hacker will now be provided with the luxury of postin desires on one's Facebook page with the help of the OAuth bearer tokens and permissions one had granted.
The use of bearer tokens is another threat. It is not secured can lead to replay attacks. For example: Use of Authorization Token can be imagined as the use of Cash. Once the cash comes in hand of another person it can easily use it. In analogy once the bearer token is acquired one can easily impersonate the owner and access the secured resources from the resource owner. OAuth is more about delegation. It tells the resource owner that the authorization server does recognize the user. But it has no means for the resource owner to determine the legitimate owner. This leads to a major  OAuth2.0 though a popular protocol, has a lot of controversies associated with it. The first and foremost is that it brings lack of anonymity. When one logs in via an authorization server it gives the application rights or authorization to view its personal details stored there. OAuth is safe only when implemented correctly. However it does process is full proof. It can lead to security attacks like phishing, where innocent users may be prompted like authorization server and asked to enter their OAuth is not a substitute for login functionality. It is developed to be used in scenarios where one requires to import its data from Website A to Website B. The very misconception in the use of OAuth2.0 is that it suffices both the needs of the application i.e. Authentication along with zation. It in fact does none. Furthermore even if OAuth relieves users from inflowing passwords for several websites it does not provide complete security. Because though the passwords won't be intercepted but in future if the ed the authorization that one provides can be exploited. For e.g., if one allows a website A (resource owner) to post on the Facebook page with the use of OAuth, and in future Website A gets hacked. The hacker will now be provided with the luxury of posting anything he desires on one's Facebook page with the help of the OAuth bearer tokens and permissions one had granted.
The use of bearer tokens is another threat. It is not secured can lead to replay attacks. For example: Use of Authorization imagined as the use of Cash. Once the cash comes in hand of another person it can easily use it. In analogy once the bearer token is acquired one can easily impersonate the owner and access the secured resources from h is more about delegation. It tells the resource owner that the authorization server does recognize the user. But it has no means for the resource owner to determine the legitimate owner. This leads to a major security concern. This is where the OpenID Co vital role. It is well elaborated in section 5.2.

OpenID Connect
OpenID Connect a successor of OpenID, is an identity layer over the OAuth2.0 protocol. It is a guideline that put in order how an identity provider and trusting associates can use OAuth2.0 to communicate identity data to one another. It allows the application to verify the owner directly. It is simple, interoperable, flexible and secure. It is better fit for microservices. As it provides both identity token along with authorization token in one request. It standardizes the security protocol. It allows Clients to verify the identity of the resource owner based on the authentication achieved by an Authorization Server, as well as to attain elementary profile evidence about the resource owner in an interoperable and REST-like style. The specificatio participants to use voluntary features such as encryption of identity data, discovery of OpenID Providers, and session management, as desired. Also the use of JWT tokens makes it more secure, as these tokens are encrypted and by applying HMAC over them. Thus attacks like replay attacks, impersonation, etc. gets eliminated.
Thus OpenID Connect would be the optimal protocol for all sorts of cloud computing technologies as it fulfils nearly all of the requirements.

Implementation Outcomes
This paper proposed an implementation of both OAuth 2.0 and OpenID Connect. The technology stack consisted of Spring Tool Suite as the IDE for developing Java applications. The graphs listed below is captured using jvisualVM. It is used to graphical sketch Java applications. It is available with the jdk OAuth2.0 Memory profile security concern. This is where the OpenID Connect plays a vital role. It is well elaborated in section 5.2.
OpenID Connect a successor of OpenID, is an identity layer over the OAuth2.0 protocol. It is a guideline that put in order how an identity provider and trusting associates can use OAuth2.0 to communicate identity data to one another. the application to verify the owner directly. It is simple, interoperable, flexible and secure. It is better fit for microservices. As it provides both identity token along with authorization token in one request. It standardizes the security allows Clients to verify the identity of the resource owner based on the authentication achieved by an Authorization Server, as well as to attain elementary profile evidence about the resource owner in an interoperable and like style. The specification set is extensible, allowing participants to use voluntary features such as encryption of identity data, discovery of OpenID Providers, and session management, as desired. Also the use of JWT tokens makes it more secure, as these tokens are encrypted and implemented by applying HMAC over them. Thus attacks like replay attacks, impersonation, etc. gets eliminated.
Thus OpenID Connect would be the optimal protocol for all sorts of cloud computing technologies as it fulfils nearly all of This paper proposed an implementation of both OAuth 2.0 and OpenID Connect. The technology stack consisted of Spring Tool Suite as the IDE for developing Java-based applications. The graphs listed below is captured using jvisualVM. It is used to graphically observe, troubleshoot, and sketch Java applications. It is available with the jdk-kit itself.
The memory usage profiles of both the protocols are attached OpenID Connect Flow OAuth2.0 Memory profile The above two figures shows that the OAuth2.0 profile uses more memory (64 MB) as compared to OpenID Connect (45 MB). This is because it requires to refresh the tokens at intervals and also the bearer tokens are stored which are used for authorization mechanism. Though it may consume memory of the system however this might be considered as beneficial due to the fact that it complicates the method of guessing the tokens from excessive memory. Thus avoiding Brute-force attacks. OpenID Connect on the other hand has no such requirement and thus consumes relatively less memory. Several of the user modifiable fields in OAuth are fixed in OpenID Connect and hence the implementation complexity is thus reduced. But this memory consumption profile makes an important component of the microservices. Attempts should be made to make it as light weight as possible, due to the limited resources available with them. Also care must be taken to make the server store as less as possibl the clients.
The comparison thus formulated are as follows:

CONCLUSION
Microservices are small, autonomous services concentrated on a single task, hence it is very essential to unburden them of concerns related to authentication and authorization. OpenID Connect caters as the best protocol for both authentication along with authorization via OAuth 2.0. This enables the services to function without the overhead of maintaining databases for storing usernames and passwords. Furthermore it also provides the best in market security combatting several serious threats to privacy the end users. This paper implemented the two models and provided a comparison and evidences supporting the use of OpenID connect for authentication in microservices.  3345 The above two figures shows that the OAuth2.0 profile uses more memory (64 MB) as compared to OpenID Connect (45 MB). This is because it requires to refresh the tokens at stored which are used for authorization mechanism. Though it may consume memory of the system however this might be considered as beneficial due to the fact that it complicates the method of guessing the tokens from excessive memory. Thus avoiding rce attacks. OpenID Connect on the other hand has no such requirement and thus consumes relatively less memory. Several of the user modifiable fields in OAuth are fixed in OpenID Connect and hence the implementation complexity is ory consumption profile makes an important component of the microservices. Attempts should be made to make it as light weight as possible, due to the limited resources available with them. Also care must be taken to make the server store as less as possible data about The comparison thus formulated are as follows: Microservices are small, autonomous services concentrated on a single task, hence it is very essential to unburden them of concerns related to authentication and authorization. OpenID Connect caters as the best protocol for both authentication uthorization via OAuth 2.0. This enables the services to function without the overhead of maintaining databases for storing usernames and passwords. Furthermore it also provides the best in market security combatting several serious threats to privacy and integrity of This paper implemented the two models and provided a comparison and evidences supporting the use of OpenID connect for authentication in microservices.