Bump github.com/lestrrat-go/jwx/v2 from 2.0.21 to 2.1.0

[dependabot]

Bumps github.com/lestrrat-go/jwx/v2 from 2.0.21 to 2.1.0.

Release notes

Sourced from github.com/lestrrat-go/jwx/v2's releases.

v2.1.0

v2.1.0 18 Jun 2024
[New Features]
  * [jwt] Added `jwt.ParseCookie()` function
  * [jwt] `jwt.ParseRequest()` can now accept a new option, jwt.WithCookieKey() to
    specify a cookie name to extract the token from.
  * [jwt] `jwt.ParseRequest()` and `jwt.ParseCookie()` can accept the `jwt.WithCookie()` option,
    which will, upon successful token parsing, make the functions assign the *http.Cookie
    used to parse the token. This allows users to further inspect the cookie where the
    token came from, should the need arise.
  * [jwt] (BREAKING CHANGE) `jwt.ParseRequest()` no longer automatically looks for "Authorization" header when
    only `jwt.WithFormKey()` is used. This behavior is the same for `jwt.WithCookieKey()` and
    any similar options that may be implemented in the future.
  # previously
  jwt.ParseRequest(req) // looks under Authorization
  jwt.ParseReuqest(req, jwt.WithFormKey("foo")) // looks under foo AND Authorization
  jwt.ParseReuqest(req, jwt.WithHeaderKey("Authorization"), jwt.WithFormKey("foo")) // looks under foo AND Authorization
since this release
jwt.ParseRequest(req) // same as before

jwt.ParseRequest(req, jwt.WithFormKey("foo")) // looks under foo

jwt.ParseReuqest(req, jwt.WithHeaderKey("Authorization"), jwt.WithFormKey("foo")) // looks under foo AND Authorization




[jwt] Add jwt.WithResetValidators() option to jwt.Validate(). This option
will allow you to tell jwt.Validate() to NOT automatically check the
default validators (iat, exp, and nbf), so that you can completely customize
the validation with the validators you specify using jwt.WithValidator().
This sort of behavior is useful for special cases such as
https://openid.net/specs/openid-connect-rpinitiated-1_0.html. However, you SHOULD NOT
use this option unless you know exactly what you are doing, as this will pose
significant security issues when used incorrectly.


[jwk] Provide a stop-gap measure to work with PEM format ASN.1 DER encoded secp256k1 keys.


In order to enable this feature, you must compile jwx with TWO build tags:
`jwx_es256k` to enable ES256K/secp256k1, and `jwx_secp256k1_pem` to enable PEM handling.
Not one, but BOTH tags need to be present.
With this change, by suppliying the WithPEM(true) option, jwk.Parse() is now

able to read sep256k1 keys. Also, jwk.Pem() should be able to handle jwk.Key objects

that represent a secp256k1 key.
Please do note that the implementation of this feature is dodgy at best. Currently

Go's crypto/x509 does not allow handling additional EC curves, and thus in order to

accomodate secp256k1 keys in PEM/ASN.1 DER format we need to "patch" the stdlib.

We do this by copy-and-pasting relevant parts of go 1.22.2's crypto/x509 code and

adding the minimum required code to make secp256k1 keys work.


</tr></table>

... (truncated)

Changelog

Sourced from github.com/lestrrat-go/jwx/v2's changelog.

v2.1.0 18 Jun 2024 [New Features]

• [jwt] Added jwt.ParseCookie() function

• [jwt] jwt.ParseRequest() can now accept a new option, jwt.WithCookieKey() to specify a cookie name to extract the token from.

• [jwt] jwt.ParseRequest() and jwt.ParseCookie() can accept the jwt.WithCookie() option, which will, upon successful token parsing, make the functions assign the *http.Cookie used to parse the token. This allows users to further inspect the cookie where the token came from, should the need arise.

• [jwt] (BREAKING CHANGE) jwt.ParseRequest() no longer automatically looks for "Authorization" header when only jwt.WithFormKey() is used. This behavior is the same for jwt.WithCookieKey() and any similar options that may be implemented in the future.

  previously

  jwt.ParseRequest(req) // looks under Authorization jwt.ParseReuqest(req, jwt.WithFormKey("foo")) // looks under foo AND Authorization jwt.ParseReuqest(req, jwt.WithHeaderKey("Authorization"), jwt.WithFormKey("foo")) // looks under foo AND Authorization

  since this release

  jwt.ParseRequest(req) // same as before jwt.ParseRequest(req, jwt.WithFormKey("foo")) // looks under foo jwt.ParseReuqest(req, jwt.WithHeaderKey("Authorization"), jwt.WithFormKey("foo")) // looks under foo AND Authorization

• [jwt] Add jwt.WithResetValidators() option to jwt.Validate(). This option will allow you to tell jwt.Validate() to NOT automatically check the default validators (iat, exp, and nbf), so that you can completely customize the validation with the validators you specify using jwt.WithValidator().

  This sort of behavior is useful for special cases such as https://openid.net/specs/openid-connect-rpinitiated-1_0.html. However, you SHOULD NOT use this option unless you know exactly what you are doing, as this will pose significant security issues when used incorrectly.

• [jwk] Provide a stop-gap measure to work with PEM format ASN.1 DER encoded secp256k1 keys.

  In order to enable this feature, you must compile jwx with TWO build tags: jwx_es256k to enable ES256K/secp256k1, and jwx_secp256k1_pem to enable PEM handling. Not one, but BOTH tags need to be present.

  With this change, by suppliying the WithPEM(true) option, jwk.Parse() is now able to read sep256k1 keys. Also, jwk.Pem() should be able to handle jwk.Key objects that represent a secp256k1 key.

  Please do note that the implementation of this feature is dodgy at best. Currently Go's crypto/x509 does not allow handling additional EC curves, and thus in order to accomodate secp256k1 keys in PEM/ASN.1 DER format we need to "patch" the stdlib. We do this by copy-and-pasting relevant parts of go 1.22.2's crypto/x509 code and adding the minimum required code to make secp256k1 keys work.

  Because of the above, there are several important caveats for this feature:

... (truncated)

Commits

• 639d231 Update Changes
• c8d35f6 Change the next minor version because of breaking changes
• ea3a57e Bump golang.org/x/crypto from 0.23.0 to 0.24.0 (#1138)
• 5fd1fa5 Fix conversion in JWE when WithUseNumber global settings is used (#1140) (#1141)
• 33d0966 Update 01-jwt.md (#1139)
• f073076 Bump github.com/goccy/go-json from 0.10.2 to 0.10.3 (#1135)
• ed00dba Bump pozil/auto-assign-issue from 1 to 2 (#1131)
• c910cfc See if this silences CodeQL (#1129)
• dfa27f9 Bump golang.org/x/crypto from 0.22.0 to 0.23.0 (#1124)
• 5f0d76f Bump golangci/golangci-lint-action from 5 to 6 (#1125)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot will merge this PR once CI passes on it, as requested by @decentralgabe.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[decentralgabe]

@dependabot squash and merge

[dependabot]

One of your CI runs failed on this pull request, so Dependabot won't merge it.

Dependabot will still automatically merge this pull request if you amend it and your tests pass.