Use JWT to authenticate separate API Microservice

Question

I am developing an app using microservices in NodeJS. I have built an auth api which handles the usual registration login etc and it issues JWT's

How do I use these to protect routes in a separate API microservice written with Express?

Do I need to use JWT with the secret to decrypt the token in the API app?

Solution 1

One common pattern here would be to use an API gateway as the entry point to your entire microservice architecture. Incoming requests for authentication would be routed to the appropriate microservice. If the credentials provided be correct, a new JWT would be returned to the gateway, which would then forward to the caller. For the actual microservice APIs which comprise your application, the gateway would check that the incoming JWT be valid before allowing the request to hit the microservice.

This answer leaves out a few things, for simplicity. For instance, often you would want to have an authorization microservice, which decides what a user is allowed to do. Also, implementing JWT can be involved. You might need a cache layer to keep track of whitelisted and/or blacklisted JWT.

Solution 2

You could write a library that you import into your other microservices that requires all routes by default to require authentication. This library could have a mechanism to validate JWT's at the microservice level, so you never need to talk to your auth api to see if a JWT is valid or not. See the description and diagram below:

Your auth server will will need to be the single issuer of JWTs to your microservices. So, when a user logs in and successfully authenticates, your auth server will issue a JWT signed with a private key (signing MUST be asymmetric - RS256 is one example) you keep on the auth server only; do not give this private key to other microservices that you wish to validate JWTs inside of. What you can do is derive a public key based on the private key you sign your tokens with and publish that to an endpoint on your auth server that requires no authentication - the public key will be represented in the form of a JWK (see link to spec). Google does something similar here. Then, in each of your microservices, your library will need to devise a way to make a GET request to the public key endpoint on your auth server every X minutes to see if there are any changes and cache the public key in each microservice. By having the public key cached in your microservice, you will be able to validate the requesting JWT inside the service that is being requested.

Then whenever a request comes into one of your microservices, the library you import will examine the requesting JWT, check its validity, and grant access/authorization if the token is valid. The beauty of using a private/public key pair and asymmetric key signing is that you can validate a token based on the public key alone, but not sign it. So as long as each service has the public key from your /cert endpoint, they can validate a token without ever needing to talk to the auth server or knowing the private key.

This will require a little more work up front, but will yield you massive amount of ease, flexibility, and peace of mind in the future knowing only one source knows your private key.

Comments

[html_programmer]

Disadvantage of this sort of common library, is that any changes to the library cause all microservices needing to pull the upgrades + redeployed. This is not needed when you just call an auth micro-service.

[Dhwanil Patel]

@Chappie Johnson can you please provide some link or demo project which describe same flow well manner?

[Marco Prins]

Easy if all your microservices use the same backend language, but a lot of work if they don't. Usually it's desirable to leverage the best language for each service, that's one of the nice things about microservices

[Shankar Regmi]

Wouldn't it cause a bottleneck in a single API gateway?