Struggling to make a valid modification to JWT "exp" value

Get Help
1

I’m testing things out using cURL with the Zoom API.

When I use JWTs generated on the Zoom App Credentials page, the cURL commands work just fine, e.g. a cURL PATCH command for updating the alternative hosts for a meeting:

curl --request PATCH \
  --url 'https://api.zoom.us/v2/meetings/1234567890' \
  --header 'authorization: Bearer { auth_token } \
  --header 'content-type: application/json' \
  --data-raw '{
    "settings": {
      "alternative_hosts": "name@fake.email;name2@fake.email;name3@fake.email"
    }
  }'

When I paste the JWT token created in the Zoom App Credentials page into JWT.io’s “Encoded” window, then modify the payload by updating the “exp” value in the “Decoded” window, I get the following error using the updated JWT token string:

{"code":124,"message":"The Token's Signature resulted invalid when verified using the Algorithm: HmacSHA256"}

This is the case whether or not I select the “secret base64 encoded” option.

This is also the case whether or not I include "typ": "JWT" in the header object (per the Zoom specs here).

Screen Shot 2021-11-14 at 7.15.24 AM
Screen Shot 2021-11-14 at 7.15.24 AM1426×1468 158 KB

What am I doing wrong and how do I generate a valid JWT with the “exp” value updated through the JWT.io gui?

Apologies for the newB smell. Thanks for your time and consideration!

3

Hi @mixelpix

Welcome to the Auth0 Community!

You cannot modify an existing token without invalidating the signature. This is the security mechanism that makes JWTs secure.

When the token expires you will typically have to request a new one.

4

Hi @dan.woda ,
Thanks for the reply… so am I understanding you correctly that if I first create a token which lasts for a week and then create a token which lasts for a day, the first one is invalidated? This seems contradictory to my experience.
What I am trying to do on the JWT.io page is use the gui to generate a new token with a modifiied “exp” value, not manually modify the encoded JWT.
Best

5

Thanks for the added context, I think I understand what you are trying to do.

No, not quite. Either token should be valid, as long as it is signed with the secret provided by zoom and is still within the exp timeframe.

Are you putting your secret in the input field?

image

6

@dan.woda oooooooOOOOOOoooooooo!

:man_facepalming:

That would probably help and is a much more secure gui that way :sweat_smile:

I’m gonna go cURL up in a ball in the corner for awhile until I am less embarrassed to be seen on teh internets.

thanks!!

7

Don’t stress! We all have those days :grinning_face_with_smiling_eyes: