0
votes

I have a Microservice architecture that uses GraphQL. It has a GraphQL Gateway, which uses schema stitching to combine all GraphQL schemas.

I'm planning to implement Authentication and Authorization as follows:

  1. Authentication - Tokens are validated by a third party (AWS Cognito)
  2. Decoding - I want to do this at the Gateway level. This is a huge benefit. It will eliminate a lot of logic across multiple microservices. This also makes it easy to migrate, in case we need to change the provider (Auth0?). Plus
  3. Authorization in services - All the services have to manage is Authorization and Business logic

Are there any pitfalls that I'm missing here? Could this be a bad idea?

1

1 Answers

1
votes

This sounds like a great use case for verification baked into the gateway so long as all underlying requests would actually need a valid token. The only thing I’d caution is not to get too clever with the logic you try to push up to the gateway to avoid long term coupling. For example, decoding and verifying the signature of JWTs is a great thing to have in a gateway since you likely want the same check performed for all routes, but trying to validate scopes or perform any per-route checks are best handled in the application itself.

For context, I currently have an nginx gateway in front of my services checking the signature of JWT tokens before passing it through, and that lets underlying services assume the token is trustworthy and prevents bad requests from ever hitting an application server.