New UI not generating tokens as previous one?

[fjakimowicz-da]

When i generate a token from the old ui using the option secret base64 encoded, all goes fine.
However if i do the same with the new one, it generates a different token, which of course fails authentication.
If i encode the token in base64 beforehand and select base64URL it also fails.
So, how can i achieve the same results that with the prev version?

[robecole1]

I'm having a similar problem where it's requiring to use a longer secret for UTF-8 when it was not a problem for the old UI. It won't be feasible to recreate every JWT I have due to needing a longer secret.

[villecoder]

We use a base64 encoded key for signing our JWTs. Does "base64url" mean I need to submit a URL? My key isn't a URL.

[mcarbonera]

This is exactly the problem I got right know. I can't find the "secret base64 encoded" checkbox on new UI. I'm using a base 64 decoder to use the tool.

[mcarbonera]

Another problem is that I can't edit decoded payload to get a new token.

[IMSoP]

The option is now a drop-down called "Encoding Format" rather than a tick-box.

[vvmichal]

It used to work, new UI/UX is broken. https://jwt.ms/ - all works fine here and it's clear design.

[IMSoP]

To clarify what's happening here: "base64url" is the name of a variant of base64 encoding designed to be safe for use in URLs and filenames: normal base64 uses + and / as output characters, base64url encoding uses - and _ instead.

So for instance, the binary data which encodes to u9GKChzIW7qMcnopQP//aQ== in normal "base64 encoding" would be u9GKChzIW7qMcnopQP--aQ== in "base64url encoding".

There appear to be two problems here:

1. The older UI accepted either variant of base64 transparently. On the other hand, it also accepted weird mixtures like u9GKChzIW7qMcnopQP-/aQ and even completely invalid strings like !"£$%^&&*&((*))
2. The new UI is rejecting strings padded with =, which contradicts the RFC section linked in the error message. So for the example above, it would only accept u9GKChzIW7qMcnopQP--aQ

So to be clear having validation in the new UI is a good thing, it just needs to be tweaked:

1. Allow both variants:
   a. either, add separate options for "Standard base-64" and "URL-safe base-64",
   b. or auto-detect which is in use, but reject invalid combinations (e.g. u9GKChzIW7qMcnopQP-/aQ)
2. Fix padding handling:
   a. Do not reject = padding in either format: u9GKChzIW7qMcnopQP//aQ== is valid in base64 and u9GKChzIW7qMcnopQP++aQ== is valid in base64url
   b. Optionally, also allow the padding to be omitted, and also accept u9GKChzIW7qMcnopQP//aQ and u9GKChzIW7qMcnopQP++aQ, although these are not strictly valid