Explore our platform and learn how it can help your application shine.
Learn about modern authentication techniques and best practices.
Learn about access management practices and technologies.
Learn to manage user accounts and access at scale.
Understand multi-tenancy, a foundation of shared computing.
Learn how to design and build successful SaaS applications.
Understand what is required to provide an enterprise-ready product.
Understand the uses and benefits of Attribute-Based Access Control.
Learn how Single Sign On (SSO) can improve security and UX.
Learn about OpenID Connect, an open authentication protocol.
Learn about SAML, a popular SSO protocol.
Learn about our history, our team, and our mission.
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:
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.
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:
You can use one of the following strategies to implement authentication in a microservices application.
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:
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:
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:
Once you have decided on your approach to microservices authentication, here are a few technical methods you can use to implement authentication in microservices.
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 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 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.
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
The Complete Guide to SaaS Multi-Tenant Architecture
Looking to take your User Management to the next level?