Microservices Drive Flexibility. But Where Does Identity Fit In?
Up until recently, most technology architecture has been monolithic, with services and code contained within a single large and complex application. Now, we’re increasingly seeing architecture broken into autonomous units—or microservices—built for specific individual functions. Microservices increase the agility and scalability of an organisation by allowing distributed teams to work simultaneously on different elements of an application, improve system resilience by minimising points of failure and the interdependence between these elements, and speed deployment for developer teams working on changes or new features—which can be done one microservice at a time.
The benefits of microservices are clear, but they also mean users are sig ning into dozens or even hundreds of applications instead of a single service. Often, these user identities exist in disparate directories, and profiles are often duplicated and contain conflicting data.
In a monolithic system, the entire system is a process. It allows admins to identify a user request, pass on access credentials, and store information about the authentication request in a data repository, all within a single firewall. With decoupled, distributed components, those users still need to be authenticated, and each microservice needs to be completely independent and execute its own logic, but it is inefficient and risky to require each service to manage security independently. As organisations look to implement this type of architecture within their tech infrastructure, they need to think about how to secure user identities within this added complexity.
Implementing unified identity and access management (IAM) for microservices thus requires new tools and technologies to create scalable frameworks and mitigate identity attacks.
Secure authentication with JWTs and API gateways
Many organisations use cookies to verify a user’s identity—this is also known as cookie-based authentication. Cookie-based authentication is stateful, meaning that records are stored on both the server and client side in order to verify users.
A more secure method of authentication is token-based authentication, which is stateless and doesn’t require data to be stored on the server. Furthermore, the server actually has no record of logged in users. Instead, every request to the server is accompanied by a token. They are encrypted in a standardised format such as JWT (JSON Web Token). The token is then used to communicate user credentials to the server, which decodes the JWT. If the token is valid, it grants access to the user in a secure method.
An API gateway can work in parallel with JWTs. It creates a common entry point for all incoming API requests to a predetermined set of microservices, authenticates the service requests, and translates protocols, as required, for each individual microservice. This allows data to be retrieved and compiled within a single request from multiple microservices, reducing overhead and creating a smoother user experience. To better secure your microservices, you can choose to build an API gateway in-house, or use pre-existing, tested solutions from third parties.
An API gateway greatly improves access controls by verifying JWTs and establishing rules around how data requests are handled while simplifying source code with a central and consistent security policy across services.
Adopt OAuth 2.0 for identity delegation
Another approach to authentication in microservices is delegation, which occurs when a user delegates a third-party system to validate their user credentials. This allows applications to get limited access to existing user accounts on the likes of Facebook, GitHub, or Google in order to authorise and authenticate the user.
Under the OAuth 2.0 delegated authorisation framework, the application requests the user’s permission to gain limited access to their account. Once that’s granted, it requests an access token from the authorisation server, and that token is used to request authentication from the resource server. This is delivered to the application as a protected resource that does not contain identifiable data about the user, thus providing a secure exchange. It also enhances usability as it mitigates the need for users to create yet another set of login credentials.
OAuth 2.0 can also work in conjunction with OpenID Connect, a security layer which helps verify the user’s identity based on the authentication conducted by the authorisation server and by obtaining access to basic user profile information.
Customise tools to meet your needs
When implementing the identity layer for your microservices infrastructure, it’s important to choose the right tools to fit your needs while keeping the security and user experience of your customers in mind. Okta’s suite of CIAM products—including Single Sign-On, Multi-factor Authentication, User Management—are all dedicated to conducting authentication and authorisation for microservices in a centralised manner that’s easy for your organisation to manage.
Microservices are helping to drive agility and scalability for companies of all shapes and sizes. And while organisations are focused on delivering their technology quickly and effectively, it’s critical that they also consider how to implement a comprehensive identity layer that secures customer information, but doesn’t disrupt customer experience.
Learn more about how to implement modern CIAM practices that keep your customer data safe while providing seamless user experiences.
