27

According the JWT RFC a JWT token can optionally have a jti which I interpret to be an a unique ID for a JWT Token. Seems like a UUID is a good value for a jti. The RFC claims that the jti can be used to prevent the JWT from being replayed. Two questions.

  • How does a JTI prevent a JWT from being replayed?
  • How often should the JTI field be regenerated? On every request? or only when a new token is generated?

The "jti" (JWT ID) claim provides a unique identifier for the JWT.
The identifier value MUST be assigned in a manner that ensures that
there is a negligible probability that the same value will be
accidentally assigned to a different data object; if the application
uses multiple issuers, collisions MUST be prevented among values
produced by different issuers as well. The "jti" claim can be used
to prevent the JWT from being replayed. The "jti" value is a case-
sensitive string. Use of this claim is OPTIONAL.

5
  • How does a JTI prevent a JWT from being replayed?
  • How often should the JTI field be regenerated? On every request? or only when a new token is generated?

I believe the answers to these two questions will depend on the application itself.

For example, if it has been programmed to only receive messages that have a unique JTI, then a replay of the same JTI can be ignored by the application.

The JTI would be regenerated in this case when it is valid for the same message to be repeated.

  • Isn't JTI an unique identifier generated by the client? I didn't quite follow how would it help to prevent replay attacks. Could you please elaborate? – Andy Dufresne Apr 14 '17 at 8:54
  • 3
    Any attacker capturing and resending a JWT would not be able to change the JTI claim without altering the signature. Therefore a replay attack is mitigated. – SilverlightFox Apr 14 '17 at 10:09
  • Got it. We will also have to add the exp claim to prevent the attacker from sending old JWT's. – Andy Dufresne Apr 14 '17 at 11:48
-1

I think Application should have some kind of storage implementation required to cross check the JWT token with already existing JTI's that server has received.

Storage implementation could be a cache memory where already used JTI values will be stored. And also this validation is entitled to expiration time so no need of having larger storage space to store JTI's.

The JTI IDs that are kept in the cache are checked against any new incoming JTI ID. The JTI IDs stored in the cache are not discarded unless the cache is full.

Please refer to below link for more info: https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/cwlp_jwttoken.html

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.