Demystifying JWT Token Debuggers
If you’ve ever followed the instructions on the DocuSign JWT access token page, you have likely ended up on Jwt.io and used their online debugger (or any other JWT token debugger for that matter) to verify your token. If you’re like me, you have also probably wondered how the debugger is working underneath the hood. How does it sign the payload? And how does it verify the signature? Let’s take a moment and demystify the workings of how the debugger works.
TL;DR
JWT token debuggers encrypt your payload using your private key and use your public key to verify the encoding.
Long version
For the purpose of this example, assume you have a payload and you’re trying to sign it using the RS256 algorithm.
Here is your payload:
|
Now, use the pyJwt library to create a digital signature of this payload with the RS256 algorithm.
First, import the library and read your private key as a string:
|
Then, define your payload:
|
Next, sign the payload:
|
There are a couple things to note here. You do not need to specify the headers to the API, as it already knows what the header looks like for RS256. And the output will look something like:
|
Now verify you would be getting the same signature from JWT.io’s token debugger:
They both match. Now, that’s an encoded string that can be safely transferred, and only someone with a public key can decode that message.
Now you might ask: why does the JWT.io generator ask for both a private and a public key? As you might have guessed, the tool will decode the encoded payload and ensure the original payload is obtained. That’s equivalent to doing:
|
That’s it. I hope this helps you understand how jwt.io token debugger works under the hood.