Authentication between microservices: Amazon API Gateway

2
votes

I have several microservices(Springboot) which I have hosted on AWS. For example Lets assume Service1 and Service2 are two micro services. Service1 is the microservice which is accessed by frontend and mobile app. Service1 calls Service2. Service2 is completely internal.

I have setup Amazon API Gateway which sits infront of Service1. And I have Authentication(Oauth) configured using cognito.

All this is working. When calling from frontend/app, the request needs to be authenticated with the API Gateway, before reaching Service1.

But my question is If Service1 needs to communicate with Service2, what sort of Authentication would be best suited, considering I am using AWS

  1. Can I resuse the token generated by API Gateway. So that Service1 can forward it to Service2 in its request and somehow Service2 verifies this with Gateway. Is it possible? If yes is it a good idea?

  2. In some cases, Service1 communicates with Service2 without the request (cronjob) from frontend/app. In this case the communication doesn't go through API Gateway, hence there will be no token generated. How should I deal with case.

I do not want to introduce Oauth Authentication to authenticate between two internal microservices. I feel its a bit of a overkill. Is there a better approach?

2
spring-bootauthenticationoauth-2.0microservicesaws-api-gateway

2 Answers

1
votes

One option that works well is to have 2 levels of API:

  • Entry point APIs are exposed to the outside world and secured via OAuth
  • Microservices are not secured via OAuth and run in a locked down virtual private cloud that only Entry Point APIs can call

Eg: * Online Sales UI calls Online Sales API * Online Sales API calls Orders and Customers microservices

User context from the OAuth access token can be passed from entry point APIs to microservices - or the token itself can be forwarded

This also performs well and avoids too many calls to Cognito.

1
votes

2 levels of APIs is a good idea as mentioned by Gary. Also yes, I think, communication between the services should be secured. Since other services will run in un in a locked-down virtual private cloud, you can just use basic auth in the services. That's how we do in our organization.