Authentication and Authorization in Microservices Architecture

The architectural style for developing applications is known as microservices (or microservices architecture). When a microservices-based application responds to a user request, it may call on many internal microservices. Each microservice has its own sphere of responsibility, which allows an extensive application to be separated into smaller parts.

We can implement microservices architecture with containers since such architecture allows one to focus on developing the services without worrying about dependencies. A cloud-native application is typically built using containers as a microservice.

Applications are developed using microservices architectures, where each service is based on a separate application. The framework allows for independently developing, deploying, and maintaining microservice architecture diagrams and services.

In this article, we discuss authentication strategy in microservice architectures.

Microservice Architecture: A Brief

Typically, microservices are small independent services within an architecture that facilitate application features and are responsible for handling discrete tasks. Microservices communicate with each other using simple interfaces to solve business problems.

Applications are typically developed faster using microservices. Many microservice architectures use Java, especially Spring Boot microservice architectures. In recent years, we have moved from monolithic applications to microservices based on our understanding of monolithic applications. The term monolithic application describes an application that contains all the functionalities of a project in one codebase.

Application and database relationships are significantly affected by the microservice architecture. There are multiple databases for each microservice, instead of sharing one database with other microservices. While it may lead to duplication of data, using a database per microservice ensures loose coupling, which is a key benefit of this architecture.

Furthermore, a separate database for each microservice lets each microservice choose the database most appropriate for its needs. It is possible to write different services in different programming languages because each service has a secure module boundary. An architecture of microservices involves a number of patterns, such as service discovery and registry, caching, API gateways and communication, observability, and security.

However, the key advantages of microservices over monolithic codebases are:

• Creating small components allows the service to scale.
• Each microservice is autonomous and flexible in terms of its technology.
• Working on various components simultaneously without affecting each other can increase productivity and velocity.
• Business functionality drives development teams.
• They can work independently without relying on other teams.

Also, Read: Monolith vs Microservices Architecture: A Detailed Comparison​

Need for Authentication and Authorization in Microservices

As we move to microservices, we will secure them differently than monolithic applications as we face security challenges in a distributed architecture. Microservices typically expose public APIs to the general public.

Monoliths are easily managed because they need to secure themselves. More risks are associated with microservices due to their more extensive attack surfaces. Each of them must take care of any weaknesses that might be exposed. An architectural monolith uses method calls to invoke components. On the other hand, Microservices may expose synchronous APIs (internal calls) to communicate with each other. Securing this requires more time and effort.

A monolith has a single-user session context shared by all internal components. An architecture based on microservices does not share user context across them, so sharing it requires explicit communication between microservices.

Thus, we require resilient, secure, and efficient authentication and authorization layers in a microservice architecture.

Difference Between Authentication And Authorization

A combination of authentication and authorization is commonly used when discussing securing applications. Despite the term interchangeability, they have different purposes in the context of app security.

Authentication

A user's identity is verified during the authentication process to grant access to the system. It verifies that you are who you claim to be. A login is required so that the user can confirm their identity.

Authorization

A user's authorization refers to whether the user is authorized to access particular information or to execute certain operations. During this process, the permissions of the user are determined.

The combination of these two principles could still cause a request to fail within the overall security flow. Authentication is the first step, followed by authorization. Authenticated users who are not authorized will still be unable to complete the request.

Authentication Types: Stateful vs Stateless

A cookie-based authentication system is stateful. The client and server must keep track of authentication records or sessions. A cookie containing a session identifier is created on the front end, allowing the server to keep track of active sessions in a database.

The token-based authentication method is stateless. No records are kept of which users are logged in or which JSON Web Tokens (JWTs) have been issued by the server. Servers use tokens to verify the authenticity of requests to verify that they are coming from a legitimate source.

In POST requests, tokens can be sent as query parameters, body data, or bearer headers. The token is generally sent as an Authorization header in the form of a Bearer [JSON Web Tokens].

When the server successfully authenticates a user, it creates a session for the user. In turn, the browser stores the session id as a cookie in the user's browser, and the cache or database stores the session data. The server attempts to load the user session context for the session store when the client tries to access the server with a given session id, checks if the session is valid, and either allows access to the resource or rejects it.

Users' sessions are stored on the client side with stateless authentication. Signing a user session with cryptographic algorithms ensures the integrity and authority of the session data. Token claims sent as cookies are verified by the server each time the client requests a resource.

This approach avoids the overhead associated with maintaining the user's session on the server side, and scaling is simple.

Services-Specific Authentication & Authorization (API Gateway)

When moving to a microservice architecture, an application's clients must communicate with the microservices. A direct connection between a client and a microservice would be one approach. This approach needs more flexibility despite having a solid coupling between clients and microservices.

Application programming interface (API) gateways serve as a single entry point for all requests. API gateways forward requests to downstream services instead of allowing clients to access multiple services. Through its central interface, it allows clients to interact with these microservices in a flexible manner.

Considering that API gateways have only one endpoint entry, they're an ideal candidate for enforcing authentication. The authentication process is consistent across the application and reduces latency (calls to the authentication service). Once authentication is successful, the security component adds user/security context to the request (identification details on the login user). It routes the request to the downstream service that checks authorization.

Also, Read: Microservices in NestJS: How to build it?​

Introducing JSON Web Tokens (JWT)

A JSON Web Tokens (JWT) is an open standard (RFC-7519) that defines a method to transmit information between parties securely. In JWT tokens, the receiver can validate the sender's identity using a list of claims.

JWT tokens are used for stateless authentication. User sessions are stored on the client side of stateless authentication.

The JWT Structure is as follows:

• Periods separate the three parts of the JSON Web token.
• An algorithm for signing is included in the header.
• 'Claims' are also included as part of the payload, which is the session data. A claim can be divided into two types: Reserved and Custom Claims.
• Reserved claims are defined in the JWT specifications and are recommended for use when creating JWT tokens.
• Among the most crucial parts is the signature. A Base64 encoded header and payload are used to calculate the signature. In the header section, cryptographic algorithms and a secret key are used for signing encode64. Tokens are verified through their signatures to ensure they have not been modified in any way.

An API gateway should be used to implement authentication checks. Microservices and API gateways can both implement authorization. To perform extensive application-specific authorization checks, authorization should be handled in the microservices specific to the application. It is possible to accomplish this by passing along the JWT along with the request. So, API gateways won't gain access to domain objects' application-specific authorizations.

Also, Read: Implementing Micro-frontend with React and Next.js​

Conclusion

Implementing authentication and authorization in Microservices Architecture is much more complex than in traditional monolithic architectures. There is a difference between authentication and authorization, even though they are both used when securing an application. Authentication involves verifying an entity's identity. The authorization process determines whether an entity is authorized to do a particular action or access specific data.