Reputation: 149
I am having a difficulty in terms of architecture and wondering if someone has some insights.
The plan
The flow:
Questions:
Upvotes: 11
Views: 8122
Reputation: 49
Your api should have a gateway that handles the Authentication and communicates to different micro-services. Its makes sense to authenticate (or reject unauthorised) users at the top level, combine responses from different services and then your clients(Web or mobile) can consume that data.
An advantage of this is that your clients only need to remember just one url.
Example: Only microservice.com is needed and not catalog.microservice.com, users.microservice.com, passport.microservice.com etc.
A single endpoint address (URL) is much easier to remember and configure than many individual API addresses.
Here is a link to an image describing this architecture.
Upvotes: 4
Reputation: 6534
The common approach in microservices architecture is to use a single authentication 'gateway', and usually it's a part of an API gateway.
So besides your passport.ms.com, you have somewhat of a proxy that will check access token from the header and if it's invalid - give an error. If the token is valid - proxy the request to corresponding microservice.
This way you don't have to repeat yourself - you don't have to implement authentication N times for each microservice.
Then, if you need more granular control - what exactly a user can access (usually called authorisation), then you traditionally implement it at each specific microservice.
In short, your microservices shouldn't care if the incoming request is authenticated - it's already been pre-filtered for them. Microservices only decide whether the user X can do action Y.
PS. You can combine API gateway with Passport/Oauth facility or you may run them separately - that's up to you. AWS already offers API gateway as a service (proving how trendy microservices are becoming) but I couldn't find any good open source analogues.
Upvotes: 12