JSON Web Token With No Expiration Date -- Such a Forever-Valid Token Is Not Your API Security’s BFF

January is a good month to review last year’s cybersecurity trends and plan the security fortification works for the upcoming year. I would recommend reading Akamai’s State of The Internet (SOTI) 2023 year end report as a starter:


One of the top stories in the above whitepaper is about JSON Web Tokens (JWTs), and how to secure them. For a good part of 2023, Akamai has received great feedback on our blog post (written by Nitzan Namer) regarding 6 commonly seen pitfalls in the use of JWTs:

  1. Allowing the server to use a token without validation
  2. Using the same private key for different applications
  3. Using a weak signing algorithm
  4. Choosing a short and/or low-entropy private key
  5. Keeping sensitive data in a JWT’s payload
  6. Confusing the keys

The author would like to conclude a 2023 year review of JWTs with one new type of pitfall that is not covered by the above list, which is a forever-valid JWT:

The above is a real-world JWT from an OTT service provider who engaged Akamai for conducting a mobile app security assessment. The JWT is used by the OTT service provider to invoke their OTP SMS generating API. What is wrong with the JWT?

Inspecting its payload, one thing stands out is the missing of the expiration time of the JWT. According to JWT’s RFC:

The expiration time should be specified by the “exp” claim in the payload JSON. It seems the developers designing this JWT confused cache-control HTTP header with JWT claims, as the JSON field “ttl” seems an idea borrowed from the time-to-live concept in the world of cache-control headers, but in the official JWT RFC, there is no mention of “ttl” whatsoever. So the “ttl” claim and its value are created out of someone’s own imagination and would have no effect on controlling the validity period of the JWT. In other words, once the attacker somehow obtained the JWT from traffic sniffing, it would become a golden ticket to abuse the SMS OTP generation API, good for eternity. Such a golden ticket is certainly the attacker’s BFF.

The developers can probably argue that they are not strictly following the JWT RFC, and this payload with “ttl” claim is their custom-made design. However, the value of 86400000 seconds would equal a duration of 1000 days. Admittedly, 1000 days isn’t forever, but it still looks dangerously long, giving the attackers ample time to carry out API abuses.

In a nutshell, it is about time to start a new year by double-checking what kinds of JWTs are being used in your organization’s API invocation. Are they securely generated? Does any JWT exhibit one of the aforementioned common pitfalls? Are there any JWT contains claims not defined by the RFC? You don’t want attackers to figure out the answers before you do.