According to the JWT RFC a JWT can optionally have a JTI which I interpret to be a unique ID for a JWT. It 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.


3 Answers 3


Great question. I think the RFC text is a little confusing.

If the JWT is intercepted in some API call, this token can of course be used again and again (unless the application creates one-time-use JWT's, but that kind of defeats the purpose of JWTs). This is not the kind of "replay attack" that JTIs protect against.

Cryptographic nonces "can be used just once", so it's only a nonce in the sense that it shouldn't be used in two separate JWT synthetizations. They more like TLS certificate serial numbers.

I would say that JTIs makes it easier to do 2 things to an API developer:

  • Store other information server-side related to a particular JWT: who requested it, from where, how many times has it been used, etc.
  • Create a server-side JWT revocation list. This can certainly make an application more secure if there are mechanisms to recognize active abuse.
  • 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.

  • 1
    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? Apr 14, 2017 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. Apr 14, 2017 at 10:09
  • Got it. We will also have to add the exp claim to prevent the attacker from sending old JWT's. Apr 14, 2017 at 11:48

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .