Microservice Authentication

With the recent rise in the microservice architecture, authentication has been gaining popularity in the tech community. Authentication in microservice involves two use cases

• User Authentication
• Service-Based Authentication

I have published an article on different ways to authenticate a web application, in which I have covered how a user can register his identity into an application, Click here to know more about user authentication. In this article, I will primarily be covering service-based authentication.

When it comes to service-based authentication, a microservice can be accessed through various means,

• By a direct user
• By other microservices
• By external/third-party application

We have open platforms like ISTIO which is very popular in Kubernetes Community and SPIFFE which stands for Secure Production Identity Framework for Everyone with its runtime environment SPIRE, both of them are based on Sidecar pattern. These sidecars abstract the complexity away from the application and handle functionalities like service discovery, authentication, traffic management, load balancing, circuit breaking, etc.

In all these standards when it comes to securing our communication it boils down to either X.509 certificate-based authentication or Token-based authentication(JWT). The difficulty in managing the certificates makes X.509 a nonstarter for most applications. In our organization, we use JWT token-based authentication for service to service authentication.

JSON Web Tokens(JWT) are an open, industry-standard RFC 7519 method for representing claims securely between two parties. The token is composed of a header, a payload, and a signature. Click here to know more about JWT

JWT solves both users accessing a microservice and a microservices accessing other microservices. Once the user successfully logs in using their credentials, a JSON Web Token will be returned. Whenever the user (consumer) wants to access any microservice (producer), the user agent will send the JWT in an authorization header. Upon receiving the token the microservice (producer) will verify the validity of the token and allow the requestor to access the protected resources.

In the same way, we can achieve service to service communication as well. In this, the consumer will be another microservice. The consumer will send the token in an authorization header to the producer, the producer will verify the token and allow the service to access protected resources.

Chain of service calls: Let’s say you have Service A calling Service B which in turn calls another service called Service C and so on. Instead of sending the same JWT to all subsequent services, if needed we can create a new JWT token on every service and add additional information like the identity of the calling service, scope of the requester, etc. We can use JWT to carry the complete information and the chain of dependencies that are used for authorization. Authorization plays a major role in the Microservice based system, which I will be covering in my next blog.

External/Third-party applications can securely access our API’s in two ways,

• API Key
• OAuth Access Token

API Key still remains as the most common identifier in many applications. The best thing about API key is its simplicity, you need to log in to any service, get the API token (key) from your setting page and use it in an application via authorization header, custom header, query string, etc. We use the API Key in custom header(X-API-Key) for external users.

OAuth: While the API Key is always traveling with your request, OAuth provides an alternative solution. OAuth 2.0 is basically a way to separate the authentication process from the access to the resource and therefore limit the exposure of the credentials. Instead of sending the credentials, the user retrieves an access token which can be used to access the resource. The most common implementation of OAuth uses the access token (which can optionally be set to expire) and refresh token (it's optional use it to retrieve new access token on expiry).

Both these options aren’t mutually exclusive. In fact, it’s possible an API could use both API key and OAuth at once.