CODEWITHSUNDEEP
javabase64jwtdecode
munHunger
munHunger

Reputation: 2999

Different Base64 decoders

I just ran into a problem with validating a JWT. The code I am running is a quite dirty hack and it takes the second component of the JWT and runs it through a Base64 decoder. However it turns out that with some super special JWTs I got some illegal characters(5f).

This was when using Base64.getDecoder().decode(claims) I read up a bit and sort of figured that I must instead use Base64.getUrlDecoder().decode(claims) to get it working(which it seems to do).

But I don't fully understand why... I found this in the docs for Base64:

Basic Uses "The Base64 Alphabet" as specified in Table 1 of RFC 4648 and RFC 2045 for encoding and decoding operation. The encoder does not add any line feed (line separator) character. The decoder rejects data that contains characters outside the base64 alphabet.

URL and Filename safe Uses the "URL and Filename safe Base64 Alphabet" as specified in Table 2 of RFC 4648 for encoding and decoding. The encoder does not add any line feed (line separator) character. The decoder rejects data that contains characters outside the base64 alphabet.

The only diff here is that Basic also uses RFC 2045, but could someone explain how that is an issue?

Upvotes: 3

Views: 2032

Answers (1)

Uwe Plonus
Uwe Plonus

Reputation: 9954

This answer is based on the comment from Alex K.

RFC 2045 is the original RFC for Base64 encoding. While using this RFC it was clear after some time that this encoding does not work for URL/URI encoding as this RFC uses the characters + and /.

Later a revised RFC (RFC 4648) was created which contained a new table with the characters usable for the encoding. This table used other characters instead of + and /.

So today you have to use one of the two tables for your base64 encoding. The first table should be used whenever possible whereas the second table should only be used if the usage of + and / leads to problems (e.g. for URLs).

Upvotes: 2

Related Questions