0

I'm designing an api from scratch and i've got some newby's questions about user registration / log in.

You can find the diagram of my session creation request -> here

First of all, is this kind of design seems ok for you ?

Second, i'm wondering what's the best way to deal with a user that open more than one session from the same agent. Should i close last session and create a new one or like on the diagram, get the last open session from the db and create new tokens from that ?

I'm sorry if all of this seems obvious for most of you but i cant find proper answer on the web.

Best wishes for this new year !

Corentin TRUFFAUT
  • 3
  • 1

1 Answers1

0

After reviewing your design, I suspect you have a confusion regarding the difference between sessions (server-side sessions) and JWTs. This answer is very useful to understand the most important differences.

However, I will give you a small summary:

Server-side sessions are used to implement stateful authentication protocols, because the state of a session is stored on the server. On the other hand, JWTs are used to implement stateless authentication protocols, because the state of a "session" (notice the quotes) is NOT stored on the server, but on the client (for example, a browser). Both approaches have their advantages and disadvantages (such as those mentioned in the answer mentioned above).

That said, using JWTs you have no way to run these processes of your design (unless you store the JWTs on the server):

enter image description here

Now, in case you are thinking of storing the JWTs on the server, let me tell you that you might be losing some advantages of the stateless approach.

I made this diagram to illustrate the simplest way to use JWTs (you could add the refresh token mechanism, but that's another matter):

enter image description here

Note that the same JWT obtained in step 2 is being sent to 2 different application servers, and they do not need to store the state of the "session" to validate the JWT, since the JWT contains all the information necessary. The only condition is that the 3 servers have the same secret key. That's it.

If you want to implement the above using server-side sessions, you would have to synchronize the application servers so that they have the same session state at all times, and this can be a bit of a complex task. This demonstrates one of the most powerful advantages of JWTs: high scalability.

Second, i'm wondering what's the best way to deal with a user that open more than one session from the same agent. Should i close last session and create a new one or like on the diagram, get the last open session from the db and create new tokens from that ?

Basically, when using JWTs you don't have to worry about these things you mention. A user should be able to request as many JWTs as he wants, and this is not a problem as long as the expiration time of the JWTs is short. That's it. However, there are times when it is necessary to invalidate JWTs, for example when changing passwords.

Tedpac
  • 862
  • 6
  • 14
  • Thank you so much for your explanation. Indeed, i used to be confused by 2 logics that i was trying to design. 1 - Handle user authentification. 2 - Keep a trace of user authentification. These 2 mechanics are called in the same time but there no real link between them. I have now a better understanding of JWT and why it's design for, thanks to you ! – Corentin TRUFFAUT Jan 03 '22 at 07:33
  • Remember that JWT was never meant as a session storage mechanism, and, in my opinion, shouldn't be used to store sessions. In fact, this is not only my opinion - http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/ Application Server 1 and 2 should be accessed through a gateway anyway, and this gateway is a perfect place to deal with sessions. Handling a distributed session storage is not that hard as you describe. – Michal Trojanowski Jan 03 '22 at 08:22
  • @CorentinTRUFFAUT I am glad the information was useful. If you wish, you can mark the answer as accepted or upvote it. – Tedpac Jan 03 '22 at 20:22
  • @MichalTrojanowski Can you please tell me where I said that JWT is used as a session storage mechanism? I suspect this confusion was introduced in the phrase "they do not need to store the state of the "session" to validate the JWT, since the JWT contains all the information necessary", but if you notice, I put the word "session" in quotes, and I only used that word there for pedagogical reasons (analogies). On the other hand, with respect to handling a distributed session storage, the complexity depends a lot on the architecture of an application (and if you have control over it). – Tedpac Jan 03 '22 at 21:08
  • What I meant is that JWTs shouldn't be used for the concept of a user session. (It really doesn't matter if you put it in quotes or not ;) ). A JWT is valid for its expiration time, which has nothing to do with whether the user is operating your app or not (so whether she has an active session). If you do use JWTs for that purpose you quickly run into the very common problem - how to log out a user? – Michal Trojanowski Jan 04 '22 at 11:16
  • Technically we can send to the user a token with an TTL = -1. But is this a good practice ? – Corentin TRUFFAUT Jan 07 '22 at 10:13