JWT and one(!) session per user / no concurrent sessions

Question

Our current app uses HTTP sessions and we'd like to replace that with JWT.

The setup allows only a single session per user. This means:

1. User signs in at Device 1
   • User is logged in at Device 1 (new Session created)
2. User signs in at Device 2
   • User is logged in at Device 2 (new Session created)
   • User is not logged in at Device 1 (Session got destroyed)

This works because there's a server-side relation between session id and user id.

---

Using JWT I could imagine to have some counter inside the user database, which gets increased with every login, i.e.:

1. User signs in at Device 1
   • JWT tokens signature contains counter+1 (and save new counter to database)
2. User signs in at Device 2
   • JWT's signature contains counter+1 and it gets increased and saved to db.

Now with every request I have to check if the incoming signature is correct for the current counter value.

This somehow makes it stateful. :(

But ... one of JWT's benefits is, that there's no need to access any database or session store for validating the token.

---

Is there some other solution for preventing concurrent logins? Maybe something that works without database access and keeps it stateless?

Solution 1

You are very close to the solution.

To do this you need the following:
1. Include iat in the token (Time when the token was issued)
2. Somewhere store the time when the user last logged in, for example in the user's profile.

Now when validating the token, do an extra check: iat (Issued At) must be at or later than the last login time. This implicitly invalidates older tokens.

Solution 2

What about closing the session of the user on any other device.

What about. every time user login, you saving the last login by type of device, and send a push notification to all the devices connected of the same type (supposedly one)?

In this case on a browser, You can send the push notification to the browser, just check what happens if that browser is closed at the moment?

In the case of mobile apps, you can send a push notification to the mobile app's with the instruction to close

Comments

[an0nh4x0r]

Thank you. This comment answer was helpful.

[moeabdol]

Excellent strategy!

[Réda Housni Alaoui]

This solution makes the token validation stateful.

[The Tahaan]

"Stateful" means keeping session information in the server. Storing the state in the DB, which is what I suggested, does NOT make it a sateful solution.

[Pasha Skender]

However if you are using any sort of microservice architecture or clustering, autoscaling etc, keeping track of this in the server will need an additional layer of complexity in case the new login request gets load balanced to a different server instance for example.