Authentication in Microservices: Approaches and Techniques | Frontegg (2024)

Authentication is the practice of verifying the identity of users or other entities as part of an access control system. A microservices application has multiple, independent services, each performing a specific predefined function. In this article, we’ll discuss the primary challenges of authentication in a microservices architecture, approaches you can use, and common techniques such as SSO and JWT.

Authentication in microservices can have three meanings:

• Authenticating end-users accessing the microservices application
• Authenticating microservices connecting to other microservices
• Authenticating external services connecting to your microservices via API

Monolith Authentication vs Microservices Authentication

A monolithic app consists of a single indivisible unit. It typically consists of a client-side user interface, a server-side app, and a database, all tightly integrated to deliver all functions in one unit. It has all the resources it needs, so there is no need for authentication within a monolithic application. Authentication only needs to be handled when users need to access the app.

By contrast, a microservices application has multiple independent components integrated via APIs. Whenever a microservice communicates with other microservices, you must make sure it is authenticated. Authentication ensures that only legitimate services and users have access to each microservice. In addition, like in a monolithic app, there is a need to authenticate end-users.

When implemented correctly, authentication and authorization are essential assets of a microservices app. It serves as an additional security check for all accessed resources, preventing security gaps and blind spots.

Microservices Authentication Challenges

In a microservices architecture, each microservice implements a specific function or part of the business logic. Each microservice access request must be authenticated and approved, which creates several challenges:

• Central dependency—authentication and authorization logic must be handled separately by each microservice. You could use the same code in all microservices, but this requires that all microservices support a specific language or framework.
• Violating the single responsibility principle—microservices are supposed to fulfill only one function. If you add global authentication and authorization logic to microservices, they now perform an additional function, making them less reliable and more difficult to manage.
• Complexity—authentication and authorization in microservices can lead to very complex scenarios. Consider that there might be users, microservices, and third-party systems accessing every microservice. This complexity can make implementation and maintenance difficult.

3 Microservices Authentication Approaches

You can use one of the following strategies to implement authentication in a microservices application.

Edge-Level Authorization

In a simple scenario, authorization only occurs at the edge, typically using an API Gateway. You can use an API Gateway to centralize authentication and authorization for all downstream microservices. The gateway enforces authentication and access control for each microservice. In this case, NIST recommends implementing mitigation controls such as mutual authentication between microservices to prevent direct anonymous connections to internal services.

This strategy has the following disadvantages:

• Less secure—if an attacker gets past the gateway, they can freely access any microservice. An API Gateway as a single access point violates the “defense in depth” principle.
• More difficult to manage—if the system is complex with many roles and access control rules, pushing all authorization decisions to an API gateway can become unmanageable.
• Limited access to development teams—typically, operations and maintenance teams set up API gateways, so the development team cannot change permissions directly. This disconnect can lead to communication and process overhead.

Service-Level Authorization

This strategy enables direct authentication and authorization for each microservice. The advantage is that each microservice has more control to enforce its access control policies. A service-level authorization architecture includes the following:

• Policy Administration Point—lets administrators create, manage, and test access rules.
• Policy Decision Point—checks which access control policy applies to the current request and evaluates whether to grant or deny the request.
• Policy Enforcement Point—provides access decisions, enforcing the access policy for specific requests.
• Policy Information Point—allows elements in the system to retrieve data about policies or receive account attributes to make policy decisions.

External Entity Identity Propagation

This strategy can make authorization decisions while taking into account user context. For example, it can change the authorization decision based on user ID, user roles or groups, user location, time, or other parameters.

To perform authentication based on entity context, you must receive information about the end-user and propagate it to downstream microservices. A simple way to achieve this is to take an Access Token received at the edge and transfer it to individual microservices. This strategy provides the most granular control over microservice authentication. However, it has two main drawbacks:

• Not secure—the content of the token is shared with all microservices, and as a result, attackers can compromise it. A possible solution is to sign tokens via a trusted issuer.
• It requires internal microservices to support multiple authentication techniques, such as JWT, OIDC, or cookies.

Microservices Authentication Techniques

Once you have decided on your approach to microservices authentication, here are a few technical methods you can use to implement authentication in microservices.

Single Sign-On (SSO)

SSO allows a user or entity to log in once and gain access to multiple systems. In the context of a microservices architecture, SSO can have two meanings:

Authentication of end-users – It’s very convenient for end-users to have one central login, preferably using existing credentials, instead of requiring new credentials to log into your app. You can use identity and access management (IAM) solutions to set up a user database and define permissions for your user-facing microservices.

Microservices can redirect users to the IAM system for authentication, receive an encrypted SSO token, and then use it to log in users on subsequent attempts. Microservices can also use the IAM system for authorization, and the SSO token can specify which resources the user is permitted to access.

Authentication of microservices – You can also enable SSO for microservices that need to connect to other microservices, or to external services requesting access via API. Here you need to authorize a software entity or service account, not human users. You can use the same IAM solution. When a software entity requires access, it can be redirected to the IAM, and the IAM system provides an SSO token they can use in future API calls.

JSON Web Tokens

JSON Web Token (JWT) provides a mechanism for sharing a set of claims or properties from a client to a microservices application in an encrypted and secure way. JWTs can also secure communication between services or pass end-user context and data between microservices.

For example, you can use a JWT token to pass the ID of the calling microservice, the ID of the client, or the system that initiated the request. You can also store authorization and authentication properties in a JWT token and share them between multiple clients and servers.

Learn more in our detailed guide to JWT authentication

OAuth API Authentication

OAuth 2.0 provides an industry-standard protocol for authorizing users in distributed systems. In the context of microservices, the OAuth 2.0 client credential flow supports secure server-to-server communication between API clients and API servers. The OAuth framework reduces the burden on developers, eliminating the need to build their own authentication mechanism in each microservice.

OpenID Connect (OIDC) extends OAuth to add federated identities, making it possible to set up delegated authorization. Together, these two layers allow developers to build systems that interact with multiple identity providers. With OIDC and OAuth 2.0, it’s also possible to retrieve a user ID by sending an access token to the user information endpoint. The path to this endpoint can be determined using an OIDC lookup.

Microservices Authentication with Frontegg

Frontegg gives you the flexibility to implement any approach you choose or need to protect your microservices. You can verify the authentication and authorization on the edge API Gateway. You also have the option of using our SDKs to verify them on the service level. These options allow you to create a robust and secure SaaS app, regardless of the use case or target audience.

GET STARTED NOW