I have a set of changes (coded using AI) that shortens the default error message into it's outer-most and inner-most messages instead of my usual "cram every piece of evidence in the error" approach. Let me know if you have an opinion one way or the other #golang #jwx
github.com/lestrrat-go/...
This time, it's really getting 70%~ performance gains for the most common use case `jwt.Sign(token, jwt.WithKey(...))`
github.com/lestrrat-go/...
#golang #jwt #jwx #jwk #jws
github.com/lestrrat-go/jwx v3.0.2 has been released. It adds some experimental QoL upgrades in the transform package, as well as some internal updates that improves interoperability of jwk.Export with third-party jwk.Key objects.
github.com/lestrrat-go/...
#golang #jwx #jwt #jwk #jws #jwe
github.com/lestrrat-go/jwx should now work with go1.24 for both v2 and v3 (alpha) lines #golang #jwt #jwx
github.com/lestrrat-go/...
github.com/lestrrat-go/...
so in v3, you will be able to tell that `jws.Verify` failed, that it's not a verification error (e.g. wrong key or signature), and that it's a parse error #golang #jwt #jwx
So, honestly. Do you consider a library _LESS SECURE_ because its underlying libraries have not received updates in the last two years? #golang #foss #jwt #jwx
github.com/lestrrat-go/...
Released github.com/lestrrat-go/...
Because there's a minor breaking change in jwt.ParseRequest(), the new release of github.com/lestrrat-go/jwx is bumping its minor version from v2.0.21 to v2.1.0 #golang #jwt #jwx