How to avoid unexpired JWT replay attack ?

[vickymicky]

JWT is created using either signed or encrypted.

Scenario:

1. User logs into the application and application client requests for JWT to auth server.
2. Auth server responds the newly created JWT with exp claim.
3. Client uses the JWT (from step 2) as an Authorization header and calls microservice.
4. Microservice validates the token either by SIGN / ENCRYPT methodology and exp claim verification etc and responds to the client.
5. User logs off from the application.

Attack Scenario:

Somehow, JWT was acquired from the user system by the hacker and the attacker keeps replaying the step 3 to overload the microservice or manipulate the request to get desired response, as long as the JWT lives.

Application could use TLS and HTTPS set up to avoid any one sniffing the network, but still if the JWT is acquired by other mechanism, these might lead to issues.

[vickymicky]

We could implement a new feature to support this something like (if it doesn't exist already),

1. https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md#binding-the-session-id-to-other-user-properties
2. https://security.stackexchange.com/questions/123536/replay-attack-example-for-validating-nonce?rq=1

High-level solution:

1. Application client generates nonce and passes it to auth server to create JWT, with passed nonce as JTI claim and sets this nonce as http-only, secure cookie.
2. Further on, whenever the JWT is passed on to microservice, it could cross check the JTI claim against the passed nonce cookie.

This way, the attacker needs the cookie set by the application to perform the attack.

We could introduce a new property called, "smallrye.jwt.verify.jti.cookie" and the value could be the cookie name which it needs to use to validate against with.
For ex: smallrye.jwt.verify.jti.cookie = nonce

sample request: curl -v -X GET http://api.microservice.com/abcservice -H "Authorization: Bearer *" --cookie "nonce=478948"

[sberyozkin]

@vickymicky I believe it is not in scope of smallrye-jwt to deal with such concerns, there is no notion of session in smallrye-jwt - it verifies bearer access tokens, even if they may be coming as cookie values. Such issues has to be dealt at the higher level, EAP, Quarkus, firewalls.
The nonce solution you propose does not work because we can't expect every user use the same nonce value.

I think what smallrye-jwt can help with is to restrict how long an access token can be accepted for, using its time to live property. For example, the token can be valid for 1 day, but you can restrict to be usable for 1 hour only from the moment it was issued. Beyond that, indeed, using HTTPS, if needed, MTLS, as well as not making access tokens valid for a long time, all all the good measures.

[sberyozkin]

@vickymicky This is a good discussion, let me convert this issue to Discussion for now, thanks