Authentication and authorization in microservices architecture
A microservice architecture is a system consisting of several small services that operate independently of each other. In such a system, authentication and authorization are more complex matters than in traditional monolithic software applications.
Authentication and authorization are the processes by which a user is granted access to a system and given the necessary rights to use it. In a conventional, monolithic software application, all this happens within the same application, but in a microservice architecture the system consists of multiple services.
In such an architecture, each microservice has its own individual task, so implementing authorization and authentication processes separately for each microservice is not fully in line with this principle. In addition, logging in to each microservice is not particularly user-friendly.
Signing in to use microservice architecture
Fortunately, these authentication problems can be solved with single sign-on (SSO) for hassle-free use of microservices. SSO allows the user to access multiple services without having to authenticate more than once. From the outside, however, the system looks to be no different from a single system that is only logged into once. In the background, a session or token is created for each user.
When a person signs on, the authentication information is transferred to the different microservices when requests are made, and each of these services can in their own particular way verify the authenticity of the sign-on. There are several different protocols on which SSO can be based, such as OAuth, OpenID Connect, SAML, and Json Web Token.
Access control
Authorization – that is, access control – for the use of software can be based on a variety of models, and the choice depends on the application and how many different access rights the users have. Often, access control is based on the role-based access control (RBAC) model or the attribute-based access control (ABAC) model.
In a microservice architecture, access control can be implemented centrally in a single service, or it can be implemented decentralized in each microservice. It is also possible to implement access control as a hybrid implementation of a centralized and decentralized model.
In a centralized access control system, all access is controlled through the same service, similarly to monolithic application authorization. In such a case, the microservice sends separate authorization requests to the access control module when an action is to be performed. This slows the operation of the service to some degree and increases the amount of interconnections between services. Microservice architectures are also designed to avoid both of these drawbacks.
In decentralized access control, on the other hand, requests are fully authorized by the individual microservices themselves. This can be done by conveying the user’s access rights along with the request to the microservice. A decentralized model is often preferable to a centralized one because it avoids unnecessary linkages between microservices.
In addition, distributed access control can be based on a service mesh architecture, where a proxy mechanism often referred to as a ‘sidecar’ is connected alongside the microservices. It can be a shared code library or a separate microservice operating alongside the microservice itself. Sidecars form a service network through which both requests and traffic pass from one microservice to another.
These sidecars handle all the authorization and authentication logic for requests, so there is no need to have these functionalities in the microservices themselves. Requests first go to the sidecar, which checks whether the request can be executed. The request is then forwarded to the microservice.
How it works: an example
The example solution assumes that microservices are provided on a private network. All external requests to microservices go through an API gateway management tool, where authorization is performed without much refinement. If the user is not authenticated, the requests are rejected. Authentication is taken care of with a single sign-on, for example using technology based on the OAuth delegated authorization framework. This means that a user can sign on to the system and use all interfaces and microservices after a single authentication.
In this arrangement, the microservices do not need to be connected to a centralized authorization service, as all the information needed for authorization is provided with the requests, and access control is performed in the sidecar proxies that are part of the configuration.
Access control is based on the user’s access rights, e.g. roles according to the RBAC model. When the system is accessed, the request is passed through the API gateway to a centralized authorization microservice, where a JSON Web Token (JWT) containing roles and permissions is returned in exchange for an OAuth token. This JWT has a short validity period and travels with the initial request to the microservice where further authorization takes place. The JWT, which contains permissions and roles, is therefore never exposed directly to the user – it is only used for traffic between microservices.
The JWT is also signed by the authorization service. Microservices verify the signature by some means, such as a public key or a certificate. The signature is intended to prevent an attack in which an attacker would know about the JWTs required by the microservices, and attempt to smuggle an artificial JWT into the requests.
The above solution makes microservices more interchangeable and reusable, as there are no direct links to the authorization service. The authorization sidecar is also reusable and configurable for different microservices. In principle, the same microservices could therefore also be used in other software. Moreover, each service in this solution has a defined role, so it is very much in line with the single responsibility principle that guides the development of microservice architectures: every class, module, or function in a program should have one job to do in it.
In my M.Sc. thesis, Implementing Authentication and Authorization in a Microservice Architecture, one aim was to survey the literature on different authentication and authorization systems for microservices in order to find the most suitable solutions for a microservice architecture
