I am implementing a solution with set of Micro Services (Spring Rest Services) with Rabbit MQ as the message broker. The Edge server is Authenticated using OAuth based Identity server. Internal Micro Sevices calls are not Authorized or Authenticated.

My objective is to secure all internal Micro Services with Authentication and Authorization. Need to secure internal communication from MiTM attack or eavesdropping.

One thing we can do is relaying the edge server's Auth Token into internal Micro Services. But if someone captures the Auth token, they can perform a Confuse Deputy attack ( act as a legitimate Micro Service ). And anyone can intercept or eavesdrop the communication in between Micro Services.

Please let me if you know a better solution for this.

Thanks in advance.

2 Answers 2


Reusing the edge token is a really bad idea as it simply gives more opportunities for it to be intercepted and wrongly used.

You should identify any risk boundaries first. So which services/data actually require additional or separate protection. Then you can create security boundaries that match. You should not generally try to secure "all" internal services independently as this is hard, and expensive, to scale. It wouldn't necessarily provide a lot of extra security anyway. Classifying systems and data is a boring pain but is the most important thing you can do.

Each boundary can then be secured by whatever method is best. Some might only need to be restricted by what addresses are allowed through (firewall), others might need additional token or certificate based security.

In an environment needing security, the edge servers would generally be considered as untrusted (semi-trusted at best) in any case since these will be the ones most exposed.


I agree with Julian's answer that you need to first understand the risks and classify data in your system.

I respectfully disagree using an edge token is a bad idea in all circumstances. If the token just specifies identity (who the caller is) and leaves authorization (what the caller can and cannot do) up to each service, it provides auditable assurance that users can or cannot perform certain tasks. For example, if the edge token contains a list of roles, usually as claims, each microservice could allow or disallow access based on the roles.

As Julian says, this assumes the edge user is significant. The originating server (the service principal instead of the user principal) could be more important or there could be claims (e.g. region or server where data is stored), requiring a different token.

I also agree it is not important to authenticate all microservices. However, I would start with the assumption you are authenticating then only remove the requirement if it is not needed. It is a lot easier to remove authentication than add it later.

  • Thanks for the update @akton. I will try to classify data in my services and will secure only the one that needs Authentication and Authorization. Commented Dec 25, 2016 at 3:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .