#Authentication in microservices with Graphql Federation 2 Gateway

10 messages · Page 1 of 1 (latest)

nova rampart
#

Hey Guys,

I am building a Nestjs Graphql Federation server and separate APIs as graphql microservices.

I have the following Microservices:

Gateway-service: Graphql Federation 2
Auth-service responsible for handling Auth tasks
Platform-service contains all the modules for business logic
and more.

okay here's what I'm thinking I would do:

In the API gateway it should check for basic token, validates it and routes to different services by placing the details from the token in the header.

Each service implements a simple gateway guard which basically does all the checks of those headers through a common module.

And then a separate auth service is used to handle register, login, MFA, device registration, sessions, admin access etc.

How about that?

Now one question I have is since we are checking for JWT at the gateway, how would I whitelist some queries or mutations at the gateway? like login itself as that will be at the auth service and if the gateway tries to check the token there then ofcourse it won't find it there so we need a use case where we can tell gateway which queries or mutations are whitelisted.

Now where can I add a directive or or decorator in the subgraph / microservice marking the graphql query in resolver public
So the gateway supergraph detects and does not perform its authentication.

icy mauve
#

Did you find the solution?

dusky dagger
#

I did the same, making an auth service to handle authentication and build authorization on top later. willSendRequest and didReceiveResponse is needed to carry over the authentication stuff to the subgraphs and for example a server side cookie to the client

#

you simply could define an array of operation names that should be public and skip the user authentication in the auth service and you can add a public decorator that adds some metadata that can be read in the AuthGuard to mark a Resolver Operation as public

#

on field level that is harder

#

you could also look into envelop

#

just to mention, most examples you will encouter with auth are for rest services, it is not easy to translate that for graphql

#

especially when it comes to get the right context for modifying request or responses