DEV Community

Building authentication for microservices using NestJS

Ale Sánchez on April 11, 2020

Before all, the code used in this post can be found at: Authentication microservice Users microservice What is NestJS? If you already know it y...

Read full post

vdelitz • May 2 '23

Awesome article on setting up simple authentication - I love how clear and concise everything is. As the article covers password-based authentication mainly, I was wondering if you've any experience in adding WebAuthn / passkeys to Nest.js?

Ale Sánchez • May 9 '23

Thank you for your comment! I haven't try those yet but maybe I will.

Gabriel Carballo • Jan 26 '22

One of the best articles I've ever read on simple authentication setup and simple communication between microservices.

It would be great to read something similar but with the Gateway interaction :)

Robert Mihai • Apr 18 '21

Hey what about a strategy where each microservice knows how to authenticate a user?

Use the AUTH microservice to generate the JWT;
Each microservice knows about the USER data source;
Each microservice will have the logic to decode that JWT;
Each request from the client will contain a cookie with the JWT;

So in a case where the AUTH microservice is down, the app will continue to function because the other microservices will know how to validate the JWT from the cookie.

What you think? :D

liemlylac • Jul 11 '20

Nice

shubh151994 • Jul 22 '20

Hi Firstly thank you for this its really helpful

I just have few doubt , auth is running at 3000 and user is running at 3010 then what is happening on port 4000 and 4010 .

Ale Sánchez • Jul 22 '20 • Edited

Hi! Thank you for reading. The difference is just that the "message" interface is listening on TCP port 4000 and 4010 and the standard HTTP interface is listening on port 3000 and 3010.

If you configure a ClientProxy with transport TCP and port 3000, those messages are not going to arrive to the auth microservice, since it is waiting for messages on port 4000.

~~Being that said, you can use the same port for por listening HTTP requests and messages, so you could configure a microservice as:~~

/* THIS WON'T WORK
app.connectMicroservice({
transport: Transport.TCP,
  options: {
    host: 'localhost',
    port: 3010
  }
});

app.startAllMicroservicesAsync();
await app.listen(3010);
DON'T TRY THIS */

Let me know if you have any more doubts :)

nigeltran • Nov 22 '21

Hi,

Thanks for the article, it is very helpful. I just wonder if you can use same port for app and service like the example above? I tried that settings, but got error that port 3000 is already taken. Do you know how to config it to the same port?

Thanks!

Ale Sánchez • Nov 22 '21

Oops... I made a mistake there, you cannot configure both things in the same port because, as you said, it's going to throw an error because the port has been already taken. I edited the comment. Sorry.

Rodolfo Lugo • Mar 17 '21

Hi Ale, first of all, thanks for this amazing guide. It's very helpful
now, the question :D.

What about the "autorization" for differents microservices?...For example, I have a microservice for "listing" and another for "payment"

The same authenticated user must be logged and requesting the both MS, but maybe dont have enough permissions to acces at the payment service.

Any recomendation/pattern to manage the permissions for each microservice? (read/view/delete)

Thanks!

Ale Sánchez • Apr 8 '21

Thank you for reading and sorry for the late reply. I think that what you want to accomplish is authorization, that is a step further than authentication.

One solution I can think of is making the auth guard aware of the microservice calling it. That way you could send to the auth microservice the token and the microservice the user is trying to access. Then you would need a place to look for user/microservices permissions and can return a response based on that.

Bastien Freiburger • Sep 15 '23

Thanks for this article, I was looking for some guidelines to build a small but effective authentication API, and it's a great starting point.
Any downside to storing the auth check response in a short term cache service ? Would it be really more efficient ? The idea would be to avoid calling the auth API for each request, but only every couple of minutes or so. The only caveat I can think of is if we want to invalidate manually a token or ban a user in the auth API, it won't propagate to other client APIs instantaneously.
Thanks again !

Gonzalo Iñiguez • Aug 5 '20

Nice! Very good explanaition. How can i implent an Api Gateway for thoose services?

Ale Sánchez • Aug 6 '20

Thanks for reading!! You can implement an API gateway yourself, acting as a "message" proxy for example. Meaning that you would keep all API endpoints in the gateway and it would be in charge of "translating" those requests into RPC (messages). Or another option is to use an existing gateway. I recommend you taking a look at Kong Gateway. It has a free, open source, version which is more than enough for a personal and even professional use.

kdi-1 • Jun 7 '20

Excellent! Thank you

Mohamad Qaddura • Jun 16 '20

My apologies to ask,
But what is the difference between the ports 4000 & 4010? i see that 4010 is only used once which looks more of a random

Ale Sánchez • Jul 15 '20

Sorry for late reply. When I build microservices, if they need to allocate a port, I usually increment the port used by 10. That's more for a local development. If you are going to deploy them in kubernetes or something like that you can use same port for everyone.