I'm not aware of any common libraries that don't. Where did you get the token cracked in your example code?

Let's suppose I search for 'jwt' and end up at 'jwt.io' (run by Auth0), which talks about what JWT is and lists a bunch of libraries. Let's say I want to use python.

One library checks for key lengths [1] and throws exceptions, another one doesn't [2] -- in fact it uses a quickstart example that should obviously fail.

[1] https://github.com/latchset/jwcrypto/ [2] https://github.com/mpdavis/python-jose

I generated this one with jwt.io, but after testing it looks like pyjwt (which is a very common library) does exactly the same thing

actually 256-bit key size is not a "big" burden for people. I've seen lots of JWT implementationens which use key sizes > 1024 bits. Consider the Mime64 encoded Bit String:

    > 8Jbr+vX5JpFZOW7P1RLs7/ArYy1Az7hrimMfcI3qqBI=

This "small" Key is already 256-Bit. if decoded to an Array in Java:

    > java.util.Base64.getDecoder.decode("8Jbr+vX5JpFZOW7P1RLs7/ArYy1Az7hrimMfcI3qqBI=").length * 8
    > res7: Int = 256

if you try to decode a jwt with it, it takes forever. (Actually I guess you also need to raise the length of the progam but it's akward since you probably don't know the correct length.

Actually I use HMAC-SHA512 with key sizes between 1024-Bit to 2048-Bit.

Edit: Typo

> Actually I use HMAC-SHA512 with key sizes between 1024-Bit to 2048-Bit.

This is utterly pointless security theater. You don't just get more security by rubbing bigger key sizes on it. The key goes through the hash function (twice, in HMAC; once via ipad, once via opad); the HMAC standard defines keys larger than the hash function's block size to go through the hash function first. With good reason, HMAC recommends key sizes to be equal to the hash function's output length; that's 16 bytes (128 bits) for MD5, and 20 bytes (160 bits) for SHA-1.

Relatedly: GCM supports large nonces, but I don't understand why you would ever use anything other than a 96 bit one. (Larger nonces go through GHASH.)