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
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.
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 the equals sign =.
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.