Preventing jwt replay attacks against the client-side

Question

I already read good answers about preventing replay attacks with JWT and a lot of resources like jwt.io.

The conclusion was that I needed to use the jti claim. From: Can I prevent a replay attack of my signed JWTs?

My schema right now is simple:

1. User logs in.
2. Server answers with a JWT.
3. Client checks if it's valid and stores it.
4. Client sends the JWT.
5. If it's valid the Server answers with a new JWT.
6. Wait 30 seconds
7. Go back to step 3.

So I started using jti, On step 4 it will use the jti stored on db from step 2 and create a new one for the next request.

While this works to prevent replay attacks on the server-side, it doesn't for the client-side. The flaw I found is: What if user redirects the traffic and always answers the same jwt, the client will think "hey this jwt is valid".

I had the brillant idea of saying "well, the jwt can't be the same as the last one". And found another flaw: now the user only needs 2 jwts to break it.

And now I have no idea on how to prevent this. I can't save all the jwts on the client side.

@edit: I forgot to add, this desktop app requires constant internet connection, it's like a game where you login and if someone logs in with your account you get kicked because your session is not valid anymore.

I'm trying to prevent multiple users on the same account at the same time, and ofc trying to prevent the user from using the same jwt and not needing to login anymore. (it's a paid software)

Answer 1

What you are saying is that you do not want a client to be able to share his valid token with another client and thereby share his session.

You have different options to achieve that:

• Use a counter in the body of your token. Every time you exchange the token, increase the counter by 1 on the server side. You remember the current value of the counter for the user on the server and verify that it matches the token you receive back. If another client uses the same token, the protocol will get out of sync and only one of the sessions will stay valid.
• Store a client specific value (e.g. the IP address) in the body of your token. Since the token is signed, the client cannot manipulate this value. You can check on server side, if the value matches the client property. So if another client with a different value for this property (e.g. coming from a different IP address) uses the token, you can detect this on the server side. If you use the IP address for this, be aware that this does not help if both are behind the same NAT or use the same proxy. If you use another property, make sure to choose something that cannot be emulated easily be different clients.
• Rethink your token strategy. Maybe a classical session management is better suited for your needs than token based authentication. Without further insight into your architecture, this is hard to tell, but you can evaluate this option and see if it solves your problem.