we have started with microservices recently, but we have some problems with implementing the Security layer.

The idea is that the request comes to Gateway, the Gateway looks to authorization header, it validates user, create JWT token and then sends request with info about user to another microservice internally. The microservice is reachable only internally, therefore it trust the JWT token.

In last project, we put basic info about users into gateway - it was able to register, login, reset password etc.

But problem is, that the core microservices was handling users too - i.e. it had some fields to validate, which is not neccesary known for gateway. The registration process need first validate at the microservice and if it was ok, it was registered on both - the gateway (password, email) and microservice (phone number, name, ...)

Problem is when it fails on one of the microservice but the other one does not know about it. Then it is registered on i.e. gateway, but not on microservice. It basically means you have to care about "transactions between microservices", which is something you dont want to (stateless microservices are best to use).

Also some requests - especially registration - must be handled very specifically, which increase code-base and complexity of gateway.


We are thinking about another solutions:

1)The users logic will be put into gateway - it is similar to current situation, but there will be no validation on core microservice, which makes it stateless. The core microservice will load new users lazily - when it opens JWT token and does not find it, it will create it.

2)We would have two microservices, one for registering and users itself, other for the other functionality, if authorization bearer is found, gateway would ask user service microservice for detail, if it is ok, it will pack info into JWT token and send next. Registration would be just passed into user service. Core microservice would be also lazily loaded.

3)We put user service functionality into core microservice itself, which would make "more monolithic" approach, but the core microservice is heavily dependent on users. (they register into groups, buy products etc.). The gateway would work similar as in case 2), it would ask core microservice about the user info and then pack JWT token and send it next.


Also take in note that we are developing small or medium projects. The whole projects usually use 1000-4000 manhours from scratch to production, the backend itself takes 500-1500 manhours (we are developing mostly mobile apps including the servers they are communicating with).

  • will you send user info in plain text to the APIGateway? In return, APIGateway send JWT token to the client? if this is the case, what about the security. Some intruder can catch the JWT and he can use it, right? – Mohamed Safeek May 7 '17 at 5:57

"The idea is that the request comes to Gateway, the Gateway looks to authorization header, it validates user, create JWT token and then sends request with info about user to another microservice internally. The microservice is reachable only internally, therefore it trust the JWT token."

This is wrong. the JWT token should be known to the client and sent with every request. All services should validate the token and not just trust it.

Your API gateway should have no logic. Its just network infrastructure

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.