Top Risks

JWT: A How Not to Guide

JWT brings performance to identity assertion and is being widely adopted, but it’s also garnering the attention of cybercriminals.
September 23, 2020
7 min. read

If there were a competition to assess the most effective technology tool of our time, applications would win hands down. Over the past two decades applications have gone through myriad transformations. In their current incarnation, applications are agile and experience-centric. Application programming interfaces (APIs) power these modern applications and with their prevalent use, cybercriminals’ enthusiasm for cracking them is equally growing. In F5 Labs’ 2020 Application Protection Report, we see how this architectural change is driving actualized risk. With 50% of the cases studied for API breaches and disclosures being authentication and authorization related, it is of utmost importance to analyze authentication as an attack vector.

What is JWT?

JSON Web Token (JWT) is a mechanism for authentication and is gaining popularity and experiencing greater adoption. RFC75191 defines JWT as a compact, URL-safe means of representing claims to be transferred between two parties. JWT can be instantiated in the form on JSON Web Signature (JWS) or JSON Web Encryption (JWE). While a JWE2 represents encrypted JSON, a JWS3 represents signed JSON data. In this article, we delve into details of JWT—specifically JWS—and look at some common exploitation techniques.

Structure of JWT

JWTs are represented as three base64 URL-encoded components separated by two dots. Each consists of a header, payload, and signature, as represented in Figure 1.

Figure 1. Sample JWT

Decoding the JWT

Running a base64 decode operation on the header and payload yields the constituents. A quick look reveals that the header field identifies the algorithm used to generate a signature, and the payload consists of the claims and signature used to validate the token (see Figure 2). JWTs support both symmetric HMAC (hashed message authentication code—a shared secret) and asymmetric signatures (a public-private key pair).

Figure 2. Decoded JWT

Compromising JWT

Signed JWTs are meant to provide integrity, however cybercriminals have discovered misconfiguration and implementation flaws that spill internal information or allow use of altered JWTs. The following are some of the common flaws:

  • Information disclosure: At times, application developers try to take advantage of the self-contained nature of JWT and enriched them with sensitive information (for example, an internal IP address). This is most common when JWTs are used to manage sessions. Enriching JWT with confidential information might boost performance but it may not be the most optimal solution and might lead to security gaps.
Figure 3. Sensitive internal information in JWT
  • Signature abuse: A JWT maintains its integrity by virtue of the signature, which gives the assurance of its authenticity. Weak implementations and poor selection of secrets have often proved to undermine the integrity provided by JWT. Figure 4 illustrates some mechanisms that have been used to abuse the signature.
Signature abuse mechanisms include unsecured JWTs, weak implementation, and weak secrets
    • Unsecured JWT: RFC7519 allow the use on no algorithm for JWT signatures. This implies that no validation will be performed with the signature on the header and payload combination.
    • Weak Implementation: Poor implementation of JWT validation has vested hackers in either downgrading a secure JWT to an unsecured JWT or using a key of their choice, undermining the system integrity. Some common examples include:

      • Setting algorithm choice to “none”: Many open source and commercial JWT libraries have fallen prey to this attack. Hackers simply switch the algorithm to none and modify the payload. Since the library implements the RFC, it disregards the signature field.
      • Using key of hacker’s choice: RFC 7515 provides for optional parameters like jku (JWK set URL), kid (Key ID), and others, which provides information about the key used to sign the JWT. Hackers undermine the signature validation process by forcing the selection of a keys, effectively allowing them to assume any role in the system.
    • Weak secrets: Brute forcing to decipher the secret used for the HMAC is possible. Just like weak passwords, the use of weak secrets makes the process easier for attackers. Multiple open sources libraries1 are available facilitating this process.
  • Replay Attack: JWTs remain valid for their defined lifetime, and since no validation request is made to the issuing server, it is prone to a replay attack.


Security misconfigurations allows the hacker to turn JWTs’ ability to provide integrity into a weakness. Authentication is a widely exploited vector for APIs, and a growing number of microservices and APIs depend on JWT for identity claims. It is strategic to understand the weak points and design defenses to protect against information disclosure and the acceptance of spoofed tokens.

Security Controls

Defending applications with stronger JWTs at a minimum requires the following security controls. Developers should also follow JWT best practice recommendations1 from the Internet Engineering Task Force (IETF).

  • Do not allow the HMAC algorithm to be set to “none”
  • Do not expose more information than necessary in client-side JWT, and utilize server-side JWT enrichment, if needed
  • Ensure the library’s JWT validation process is sound
  • Ensure that external inputs like ‘kid’, ‘jku’ and others are not blindly trusted
  • Use jti (JWT ID) claim to protect against replay attacks
Join the Discussion
Authors & Contributors
Shahnawaz Backer (Author)






What's trending?

Forward and Reverse Shells
Forward and Reverse Shells
09/15/2023 article 5 min. read
Web Shells: Understanding Attackers’ Tools and Techniques
Web Shells: Understanding Attackers’ Tools and Techniques
07/06/2023 article 6 min. read
What Is Zero Trust Architecture (ZTA)?
What Is Zero Trust Architecture (ZTA)?
07/05/2022 article 13 min. read