JSON web tokens (JWTs) are a standardized format for sending cryptographically signed JSON data between systems

JWT Tokens includes 3 parts, and they are seperated by dot Header + Paylod + Signature:

• Header and Paylod part are just Base 64 - url encoded JSON objects
• The header contains metadata about the token itself, while the payload contains the actual data/ information.
• The server that issues the token typically generates the signature by hashing the header and payload.
• This mechanism provides a way for servers to verify that none of the data within the token has been tampered with since it was issued:
• As the signature is directly derived from the rest of the token, changing a single byte of the header or payload results in a mismatched signature.
• Without knowing the server's secret signing key, it shouldn't be possible to generate the correct signature for a given header or payload.

JWT vs JWS vs JWE

• The JWT spec is extended by both the JSON Web Signature (JWS) and JSON Web Encryption (JWE)
• When people use the term "JWT", they almost always mean a JWS token.
• JWEs actual contents of the token are encrypted rather than just encoded.

Exploiting flawed JWT signature verification

• Accepting arbitrary signatures
• JWT libraries typically provide one method for verifying tokens and another that just decodes them. For example, the Node.js library jsonwebtoken has verify() and decode()
• Occasionally, developers confuse these two methods and only pass incoming tokens to the decode() method.
• This effectively means that the application doesn't verify the signature at all.
• Accepting tokens with no signature
• the JWT header contains an alg parameter. This tells the server which algorithm was used to sign the token and, therefore, which algorithm it needs to use when verifying the signature.
• This is inherently flawed because the server has no option but to implicitly trust user-controllable input. In other words, an attacker can directly influence how the server checks whether the token is trustworthy.
• JWTs can be signed using a range of different algorithms, but can also be left unsigned. In this case, the alg parameter is set to none, which indicates a so-called "unsecured JWT".
• Brute-forcing secret keys using hashcat
• You just need a valid, signed JWT from the target server and a wordlist of well-known secrets. You can then run the hashcat command, passing in the JWT and wordlist as arguments
• Hashcat signs the header and payload from the JWT using each secret in the wordlist, then compares the resulting signature with the original one from the server. If any of the signatures match, hashcat outputs the identified secret, along with various other details:
• Injecting self-signed JWTs via the jwk (JSON Web Key) ,jku (JSON Web Key Set URL), kid (Key ID) parameters
• jwk (JSON Web Key) - Provides an embedded JSON object representing the key.
• jku (JSON Web Key Set URL) - Provides a URL from which servers can fetch a set of keys containing the correct key.
• kid (Key ID) - Provides an ID that servers can use to identify the correct key in cases where there are multiple keys to choose from. Depending on the format of the key, this may have a matching kid parameter.

These user-controllable parameters each tell the recipient server which key to use when verifying the signature.

Reference link: https://portswigger.net/web-security/jwt