Updated System.IdentityModel.Tokens.Jwt and Microsoft.IdentityModel.JsonWebTokens to latest to address CVEs

[chgl]

What issue does this PR address?

Resolves CVE-2024-21319

Important: Any code or remarks in your Pull Request are under the following terms:

If You provide us with any comments, bug reports, feedback, enhancements, or modifications proposed or suggested by You for the Software, such Feedback is provided on a non-confidential basis (notwithstanding any notice to the contrary You may include in any accompanying communication), and Licensor shall have the right to use such Feedback at its discretion, including, but not limited to the incorporation of such suggested changes into the Software. You hereby grant Licensor a perpetual, irrevocable, transferable, sublicensable, nonexclusive license under all rights necessary to incorporate and use your Feedback for any purpose, including to make and sell any products and services.

(see our license, section 7)

[sievajetnamdar]

Can we merge this already? Im waiting for this fix😄 @josephdecock

[leastprivilege]

You can simply update the package version in your host. No need to wait for other libraries to update their dependencies.

[carlin-q-scott]

@leastprivilege Yes, we can do that. And I did. But there's 10s of thousands of consumers of this package. Wouldn't it be more efficient for your company to address the vulnerable dependency? It has been over a month since this PR was created for a CVE 6.8 vulnerability.

[brockallen]

There is precedence for our approach: aspnet/AspNetKatana#522 (comment)

[carlin-q-scott]

Yes, people do that because we can't wait months for the package maintainer to merge their PR.

[brockallen]

The browbeating tone of your message makes it difficult to have an unimpassioned and productive conversation. Please keep it professional.

Back on topic, can you show other examples from Microsoft where they have done such a change? We've taken their approach and guidance on this topic for years. In our experience this is not practical to patch every time a such a dependency changes, especially given the various dependency chains. But if there's new and/or updated guidance, we're more than happy to consider it.

[goldsam]

Isn't this why dependabot is a thing? Just click the merge button and tada🪄

Some companies don't use a dependabot and will be exposed to vulnerabilities. As Uncle Ben once said, "with great power comes great responsibility." Lesser known is quote from Aunt May: "Responsible young men update their vulnerable package dependencies." 😉

[brockallen]

I appreciate everyone's passion here, but we're in a difficult position here. I'll try to explain below.

Isn't this why dependabot is a thing? Just click the merge button and tada🪄

Unfortunately, it's not that simple. Given the historic issues with diamond dependency problems specifically related to code quality and frequent breaking changes in minor and patch updates to Wilson, we took the approach a long time ago to only reference the exact versions of downstream dependencies that were the same ones as targeted by the base version of .NET and/or ASP.NET we were targeting (e.g. .NET 6 or .NET 8).

This is why, in addition to the guidance we sought from Microsoft about on how to handle these issues, and the fact that hosts using our library have a solution to getting the updated version of the dependency, this hasn't been the highest priority.

We also have not had the time to actually verify that the newer version hasn't broken something else (as they have often done in the past).

So hopefully this provides some context. We do have time on our upcoming schedules to do feature work here, and this will be one of the topics we look into.

Thanks again.