enter image description here

I am evaluating the above service design where I want to have mechanism to pass a user through multiple microservices. In this simple example, the user goes through a sign-up process and once done, the user is redirected to another microservice (B).

The session-id for microservice A is stored in a session store. However, when the user is redirected to microservice B then a new session-id is generated by microservice B and so this is stored as well in the session store.

This allows the user to traverse back and forth between microservices. Are there any security implications with this design?

  • Is this a practical design or just a hypothetical? Assuming this is the web, and assuming the microservices are unified into the same site (eg, mysite/sign-up and mysite/), both microservices would see the same cookies, and therefore the same session – Mike Caron Dec 10 '19 at 22:16
  • Each microservice can only decrypt it's own cookie as each service issues it's own cookie and encrypts it with its own private key. – Mojo Dec 11 '19 at 9:01
  • Why do you want individual private keys for microservices? – Limit May 9 '20 at 5:10

The biggest possible security implication I can see with the details presented is that you might accidentally DoS your visitors if every individual service has its own session, and therefore session cookie. Once you hit the cookie limit (typically 4096 bytes), browsers will start ignoring cookies, possibly arbitrary ones, and that will cause sessions to start being dropped.

Another possible vulnerability is that if you have to examine multiple sessions in order to do work, it's possible that a malicious user might send a large number of different session ids, real or otherwise, and force your services to examine each one, which at best would cost CPU cycles (and thus money), and at worst cause a wider system DoS.

Both of these would be mitigated by only having a single session for the user.

  • Even with single sessions a malicious user could fire off many different sessions ids in the hope that they hit the jackpot. With regards to the cookie limit, it's only two cookies: one of the either the login/signup stage, and then one for the rest of the services. So at most there would be two cookies. The cookies are just encrypted JWT tokens so pretty lightweight – Mojo Dec 11 '19 at 9:06
  • I don't see how it would lead to DoS - could you expand on that bit – Mojo Dec 11 '19 at 9:11
  • 1
    I mean, I explained it pretty clearly in the answer. If you have many cookies, then you might exhaust the cookie storage, and some cookies will get lost. But, if you only have two... it really begs the question as to why not just one? – Mike Caron Dec 11 '19 at 16:29

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.