I am having a difficulty in terms of architecture and wondering if someone has some insights.
The plan
- I will have multiple microservices (different laravel projects, catalog.microservice.com, billing.microservice.com) each providing an API.
- On top of these will be an angular fronted consuming those APIs.
- I will have another micro service (passport.microservice.com) for auth now thanks to laravel 5.3 passport this is even easier.
The flow:
- User goes to catalog.microservice.com
- user need to authenticate and provides a user and password
- request is made by angular (aka client) to passport.microservice.com through password grand type to get an authorization token
- now that I have a token I am authorized to call a resource from catalog.microservice.com
- catalog.microservice.com needs to know if the token is valid and makes a request (some kind of middleware?) to passport.microservice.com
- passport.microservice.com returns the user, scope etc.
Questions:
- Is this a good approach?
- The token validation in catalog.microservice.com can be a middleware?
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.
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.
I'm no expert but that flow looks okay to me if you are required to use different applications for this.
Regarding your second question, yes this can be middleware
来源：https://stackoverflow.com/questions/39126827/laravel-passport-oauth-and-microservices