Authentication & Authorization in a microservices architecture

Introduction

In every application, authentication and authorization are crucial components. A user can get access to a system and grant the required permissions to utilize it by using authentication and authorization. All of this occurs within a single software programme in a traditional, monolithic software design, while the system with a microservice architecture comprises many services.

Moving to microservices will lead you to the realization that protecting the microservices requires a different approach than securing a monolithic programme.

Questions like "Where and how do I implement authentication and authorization?" and "How do I authorise users to certain actions?" may arise when creating the solution. This blog will introduce a solution to these problems.

We shall examine the following in this blog:

• Microservices Authentication vs. Monolith Authentication
• In a microservice architecture, how do authentication and authorization work?
• What issues do we have with microservices authentication?
• What is the most effective way to authenticate and authorise users in microservices?

Monolith Authentication vs Microservices Authentication

A monolithic application consists of a single, unbreakable entity. It generally includes of a client-side user interface, a server-side programme, and a database, all of which are closely connected to offer all services as a single entity. A monolithic programme does not require authentication since it has access to all of the resources it requires. Only when users need to access the programme does authentication need to be handled.

A microservices application, in contrast, integrates several separate services using APIs. You must ensure that a microservice is authenticated before it interacts with another microservice. Only authorised users and services can access each microservice thanks to authentication. Additionally, users must be authenticated, just as in a monolithic app.

Authentication and authorisation are valuable components of a microservices application when properly done. It prevents security holes by acting as an extra security check for all resources that are accessed.

How do Authentication and Authorization work in a Microservice Architecture?

The application will utilise the user's username and password to validate the user's identity during authentication. Although there are several ways to authenticate users, the most common and effective methods are username and password. On the other side, when it comes to authorization, we look for things that users can accomplish, such being allowed to take certain activities.
In a monolithic design, the application issues a JWT (session) token when the initial user authenticates. User roles and user information, such as name, email, and username, should be carried via JWT. The case JWT token will be used whenever a user wishes to execute any action to identify the user and determine whether or not the user has sufficient rights to accomplish that activity.

Making the microservices accountable for managing authorisation might be a preferable option. The JWT should be sent to the microservice by the client with the request since it contains the roles that have been assigned to the user. The token has already been validated when the microservice receives the request since the auth service handles authentication. The microservice may now determine whether the user is authorised for the intended request using the roles that have been assigned to the user performing the request. By doing this, the application-specific implementation only has to be done once. This has the disadvantage of increasing authorization dispersion among several services. This is harder to handle when there are several positions that change often.

What problems do we face when performing Authentication and Authorization in Microservices?

Global logic needs to be implemented repeatedly in each microservices.

Each microservice in the microservice architecture must handle authentication and authorisation, and each microservice must regularly implement this aspect of the global logic. Even if we may reuse some of the code, all microservices will become dependent on one code base and its version, which limits the flexibility of the microservices language or framework choice.

Microservices are stateless, distributed, and independent

The microservice receives a request from a stateless system, which then delivers the response without keeping any data in between. Stateful systems, on the other hand, monitor data, anticipate a response, and, in the absence of one, resubmit the request. Additionally, because microservices have autonomous components and remote databases, obtaining data from many sources will be challenging.

What could be the best possible solution to Authentication and Authorization in Microservices?

Here are a few technical techniques you may use to create authentication in microservices once you've decided on your approach to it.

• JSON Web Tokens
• OAuth2/OIDC
• Single Sign On

JSON Web Tokens

An encrypted and secure method of sending a collection of claims or attributes from a client to a microservices application is provided by JSON Web Token (JWT). JWTs can transport end-user context and data between microservices or secure communication between services.

A JWT token can be used, for instance, to transmit the client ID, the system ID, or the ID of the calling microservice. A JWT token may also be used to hold permission and authentication characteristics and distribute them among several clients and servers.

OAuth2

An industry-standard protocol for user authorization in distributed systems is provided by OAuth 2.0. The OAuth 2.0 client credential flow provides secure server-to-server communication between API clients and API servers in the context of microservices. By removing the requirement for them to create their own authentication method in each microservice, the OAuth framework eases the strain on developers.

Delegated authorisation may be set up thanks to OpenID Connect (OIDC), which extends OAuth to include federated identities. Together, these two layers give programmers the ability to create systems that communicate with many identity providers. A user ID may also be obtained via OIDC and OAuth 2.0 by delivering an access token to the user information endpoint. An OIDC lookup may be used to discover the route to this endpoint.

Single Sign-On

For microservices that must connect to other microservices or to external services demanding access through API, SSO can also be enabled. In this case, a software entity or service account—not actual users—needs to be authorised. The same IAM solution is available. The IAM system may be contacted when a software entity needs access, and it will then provide them with an SSO token to utilise for further API requests.

Conclusion

It is significantly more difficult to deploy authentication and permission into microservices than it is in a conventional monolithic design.

While both phrases are used in the context of safeguarding an application, authentication and authorisation don't refer to the same thing. Verifying an entity's identity is the goal of authentication. The process of assessing whether an organisation is permitted to carry out a given activity or access a particular set of data is known as authorization.

Applications inside a microservice architecture often have authentication and authorisation handled in a centralised service that handles this. There are several options for this, including IdentityServer4 (.NET), WSO2 Identity Server (Java), and OAuth2orize (Node.js). These services support the underlying, widely used authentication and authorisation protocols OAuth2 and OpenID Connect.

Authentication check implementation ought to come to an end inside the API gateway. Authorization implementation is possible in both the API gateway and the microservices. The authorisation should be handled in the relevant microservices in order to do thorough application-specific authorization checks. The JWT can be sent together with the request to accomplish this. This will prevent the API gateway from learning about domain object authorisation that is particular to an application.

References:

https://medium.com/swlh/authentication-and-authorization-in-microservices-how-to-implement-it-5d01ed683d6f

https://www.sailpoint.com/identity-library/difference-between-authentication-and-authorization/#:~:text=Simply%20put%2C%20authentication%20is%20the,people%20can%20come%20on%20board.

https://www.okta.com/identity-101/authentication-vs-authorization

https://www.onelogin.com/learn/authentication-vs-authorization