11

I have a bunch of microservices that are only accessible externally via an API Gateway.

My API Gateway is set up as an OAuth Resource and validates the token (Checks signature etc.) before passing the request downstream to one or more microservices.

Whilst my microservices need the token in order to verify scopes and claims, is there any need now for this service to validate the token as well?

It seems a bit overkill yet I cannot find any advice online about this scenario.

Is validating the token at the API gateway good enough? Or is it best practice to validate it again later?

Improve this question
2
  • 1
    Are these same services accessible when bypassing the gateway internally?
    – Greg Burghardt
    Aug 2, 2018 at 19:28
  • I cannot find any advice online about this scenario. Because it depends on several factors that vary from project to project. Probably in most of the developments out there claiming to be MS architecture, they don't need it. Moreover, within such architectures, there should be an auth server that will do this instead of the services (and instead of the gateway of course). Is the auth server who allow the request to pass or not.
    – Laiv
    Aug 3, 2018 at 6:33

1 Answer 1

Reset to default
3

If any internal calls can bypass the gateway either validate the token in every microservice, or force all calls — internal and external — to go through the gateway.

Personally I wouldn't trust internal calls either. Have them go through the gateway, even to the point of limiting traffic via firewall rules. Know who is talking to who, and why. This helps limit your surface of attack if someone ever breaches your network.

This does introduce a single point of failure, but this risk can be mitigated by load balancing servers and having fail-over servers on hand in case of catastrophic problems.

On the other hand if every service validates the token, and anything about the validation process changes you have N+1 services to update.

Improve this answer
3
  • I have heard the argument that "you can't trust internal traffic either." But exposing an application to a (relatively) small number of users on an intranet is a far cry from exposing the same application to the public Internet. It's essentially the same as the difference between a speaker magnet and a cyclotron.
    – Robert Harvey
    Aug 2, 2018 at 22:56
  • 2
    @RobertHarvey: I think the justification I've heard for "don't trust internal traffic" isn't so much the legitimate traffic as it is walling off the network in case of intrusions. Especially if your system handles PII, health, financial or sensitive information. If someone breaks in they are limited in what else they can talk to.
    – Greg Burghardt
    Aug 3, 2018 at 0:53
  • If someone gets in your system, the token validation would be the less of your problems. Whether you should or not validate the token within a trusted network (and not accessible by foreigns) might depend on the kind of validations we do and if there's any again not performing the validation. As for instance, performance. Back to your reasoning. Would you implement TLS in a private network? Would you encrypt communication between two components running next to each other? The likely answer is depends.
    – Laiv
    Aug 3, 2018 at 6:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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