Azure B2C Microservice Authentication and GraphQL Layer

0
votes

We have few micro-services that are used by a UI. Azure B2C is our auth provider. Each micro-service(API) requires an access token and needs to talk to a database for authorization. This database has role based access permission.

This is how it looks today:

enter image description here

With this we have two problems:

  1. As Azure B2C do not allow adding scopes from multiple resources into one access token, we have to get multiple access tokens.
  2. We are now at a stage where the UI need to call two or more APIs to display the data on one page.

We wanted to use GraphQL as an API Gateway. Something like this:

enter image description here

All the micro-services are placed inside a private vnet and only GraphQL API is allowed to talk to them. GraphQL Layer handles all authentication and authorization.

Now the questions are:

  1. Do you see any problems with this approach?
  2. Is it okay to use a client and secret for communication between GraphQL layer and other API's? or Is there an provision in Azure B2C that can do this validation with out GraphQL layer requesting individual access tokens?
  3. what are the additional advantages of adding Azure API Management to this (other than logging, analytics, rate limiting etc)? Do I need to worry about SSL termination?
1
node.jsoauth-2.0graphqlmicroservicesazure-ad-b2c

1 Answers

0
votes

Option 2 looks like a good architecture.

A common pattern is for the UI to call a dedicated 'entry point' API, which then orchestrates calls to microservices in a private network - as in your second diagram.

  • Eg an Online Sales UI calls only an Online Sales API

This also helps to keep UI specific requirements out of microservices and keep responsibilities clean.

In OAuth terms as you say there will be a single resource - the entry point API - and you should only need a single access token.

The entry point API's token (or its claims) can then be forwarded directly to Microservices and used to identify the user there if needed.

I'd avoid getting additional tokens for microservices and just enforce authorization based on roles from your user database.

In some cases it may also make sense to also enforce rules such as 'Online Sales API not allowed to call Payroll microservice'.

Personally I would develop entry point APIs using the same technology as microservices.