search

teamhanko / hanko

Authentication and user management system with passkey superpowers
https://hanko.io
Other
5.56k stars 792 forks source link

chore(deps): bump github.com/lestrrat-go/jwx/v2 from 2.0.21 to 2.1.0 in /backend #1497

Closed dependabot[bot] closed 2 weeks ago

dependabot[bot] commented 2 weeks ago

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


Dependabot compatibility score

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 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 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)