Menu
In Notepad++, I'm having trouble decoding a JWT. When I try to use Plugins -> MIME Tools -> Base64 Decode with:
eyJleHAiOjE0NDIzNjAwMzQsIm5iZiI6MTQ0MjM1NjQzNCwidmVyIjoiMS4wIiwiaXNzIjoiaHR0cHM6Ly9sb2dpbi5taWNyb3NvZnRvbmxpbmUuY29tLzc3NTUyN2ZmLTlhMzctNDMwNy04YjNkLWNjMzExZjU4ZDkyNS92Mi4wLyIsImFjciI6ImIyY18xX3NpZ25faW5fc3RvY2siLCJzdWIiOiJOb3Qgc3VwcG9ydGVkIGN1cnJlbnRseS4gVXNlIG9pZCBjbGFpbS4iLCJhdWQiOiI5MGMwZmU2My1iY2YyLTQ0ZDUtOGZiNy1iOGJiYzBiMjlkYzYiLCJpYXQiOjE0NDIzNTY0MzQsImF1dGhfdGltZSI6MTQ0MjM1NjQzNCwiaWRwIjoiZmFjZWJvb2suY29tIn0
I get:
Length of selected text (not including EOL) to be decoded is invalid. It should be mod 4.
But if use www.base64decode.org it works fine:
{"exp":1442360034,"nbf":1442356434,"ver":"1.0","iss":"https://login.microsoftonline.com/775527ff-9a37-4307-8b3d-cc311f58d925/v2.0/","acr":"b2c_1_sign_in_stock","sub":"Not supported currently. Use oid claim.","aud":"90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6","iat":1442356434,"auth_time":1442356434,"idp":"facebook.com"}
Why is that? Am I using Notepad++ incorrectly?
The value I'm using came from Azure AD B2C: Token reference.
Update 2020/01/28
I just tried the above JWT and Plugins -> MIME Tools -> Base64 Decode is able to handle this use case now 🎉. I'm on v2.5 of the plugin. I'm guessing v2.2 "fixed" this:
Npp mime tools v2.2 release
donho released this on Nov 28, 2018
Enhance base64: decode/encode without padding
900
To encode or decode Base64 data you need to first highlight the entire range of data you want to be encoded or decoded. Next, click on “Plugins” in the top bar, then “MIME Tools”. In the second level of the menu you can see all of the Base64 encode and decode options.
With padding, a base64 string always has a length that is a multiple of 4 (if it doesn't, the string has been corrupted for sure) and thus code can easily process that string in a loop that processes 4 characters at a time (always converting 4 input characters to three or less output bytes).
Since Base64 uses 24-bit sequences, padding is needed when the original binary cannot be divided into a 24-bit sequence.
Two variants of Base 64 encoding RFC 4648 lists two common variants: Base 64 encoding using alphanumeric chars, + , / , and = as the padding character. Base 64 encoding with URL and Filename Safe Alphabet using alphanumeric chars, - , _ , and also = as the padding character.
Short answer:
To make the string decodable you have to make the number of characters in the encoded string an integer multiple of 4. Meaning you have to divide the number of characters by 4 and not get a remainder. In this particular case, you have 443 characters. Adding a = at the end will make it decodable.
Long answer:
Base64 encoding uses something called padding. The number of characters in the output has to be an integer multiple of 4. If the actual output doesn't fulfill that requirement the encoding algorithm will add additional padding characters to the output. The padding character is usually =.
There are some examples on Wikipedia of how this works. You can also see this SO post.
There is a difference between "ordinary" base64url encoding, and the base64url encoding used with JWT: JWT skips the padding characters. They are simply not added. So any decoding algorithm for JWT has to take that fact into account.
Ordinary base64 decoders will not allow encoded strings without padding, as input (if padding was required). Most decoders have an assertion at the beginning of the decoding algorithm where they check the length of the input string and check that the length % 4 = 0. You can see that from the error message
Length of selected text (not including EOL) to be decoded is invalid. It should be mod 4.
The length is wrong because the padding characters are missing.
So using decoders that handle padless strings is the way to go. Andre already linked one site. Here is another.
90
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
