Mika Tuupola

It seems `firebase/php-jwt:6.0.0` is not a throw in replacement. It is also possible that it requires dropping support for older versions since handling of keys is quite different. Will investigate...

CVE-2021-46743 is not a vulnerability per se but a footgun if user against [all advice](https://github.com/tuupola/slim-jwt-auth#algorithm) enables both `RS256` and `HS256` in the config.

No, dropping support for old versions of dependencies is not a BC break. It seem currently `5.x` has most downloads, but `6.x` is rising too. https://packagist.org/packages/firebase/php-jwt/stats

One of my pet peeves is CVE scanners which blindly check for version numbers but not if code is actually vulnerable. That said it is a good idea to upgrade...

I know. Just last week I had to spend considerable time explaining a corporate that CentOS 7 servers are not vulnerable even when their CVE scanner warns about "vulnerable" versions...

Yes it is still the plan. Probably for 4.x though, since it can be considered a bc break.

@alokdhir technically there is almost no difference. The deployment is still unsecure if it trusts an user settable `X-Forwarded-Proto` header. Request itself still is not https. @Frzk Sorry did not...

Yep, big token size is a problem with JWT. For smaller token sizes you could use for example Branca tokens together with MessagePack payload. This is what I am using...

For the above mentioned usecase md5 would not work since it is a hashing algorithm. It is one way only. You can make a hash from the token but you...

Confirmed, I do not remember why this is the case. Seems to date back to 2.x branch. Changing this behavior by default would be a BC break, so maybe add...