2

I am trying to figure out how I will manage sessions using json web tokens in a microservice architecture.

Looking at the design in this article what I currently have in mind is that the client will send a request that first goes through a firewall. This request will contain an opaque/reference token which the firewall sends to an authorization server. The authorization server responds with a value token containing all the session information for the user. The firewall then passes the request along with the value token to the API, and the value token will then get propagated to all the different microservices required to fulfill the request.

I have 2 questions:

  1. How should updates to the session information in the value token be handled? To elaborate, when the session info in a token gets updated, it needs to be updated in the authorization server. Should each service that changes the token talk to the authorization server?
  2. Should all the microservices use this single token to store their session info? Or would it be better for each service to have a personalized token? If it's the latter, please explain how to adjust the design.
Kacy
  • 3,330
  • 4
  • 29
  • 57

1 Answers1

3

A very(!) significant "fly in the ointment" of this kind of design ... which requires careful advance thought on your part ... is: “precisely what is meant by ‘session’ information.” In this architecture, “everyone is racing with everyone else.” If the session information is updated, you do not and basically cannot(!) know which of the agents knows about that change and which does not. To further complicate things, new requests are arriving asynchronously and will overlap other requests in unpredictable ways.

Therefore, the Authorization Server must be exactly that ... and, no more. It validates (authenticates ...) the opaque token, and supplies a trustworthy description of what the request is authorized to do. But, the information that it harbors basically cannot change. And specifically, it cannot hold “session state” data in the web server sense of that term.

Each microservice provider must maintain its own “tote board” *(my term ... “its own particular subset of what in a web-server would be ‘the session pool’”), and it is desirable but not always feasible that its board would be independent of the others. Almost certainly, it must use a central database (with transactions) to coordinate with other service-providers similarly situated. And still, if the truth is that the content of any of these “totes” is causally related to any other, you now have an out-of-sync issue between them.

Although microservice architecture has a certain academic appeal, IMHO designs must be carefully studied to be certain that they are, in fact, compatible with this approach.

Mike Robinson
  • 8,490
  • 5
  • 28
  • 41
  • Your explanation really helps and does make sense. I just want to clarify something. In order to implement these "tote boards", I'm guessing I would make separate "tote board" services that essentially hold the sources of truth for the other services to query. And from there I just have to deal with whether I want consistency or availability. Does that sound right to you? Although with this design it seems like it doesn't get the benefit of passing around all the session state for a client in a token :/ – Kacy Jun 29 '16 at 16:54
  • No, I don't think that you could implement a tote-board service, because updates need to be atomic. Microservice architectures can frankly be very problematic when things *change,* because e.g. two requests could be started at about the same time, even on different servers, could run at different rates, and could "race" in quite-unpredictable ways. – Mike Robinson Jun 30 '16 at 01:30