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:
1. This feature is provided solely as a stop-gap measure until such time Go's stdlib
provides a way to handle non-standard EC curves, or another external module
is able to solve this issue.
2. This feature should be considered unstable and not guaranteed by semantic versioning
backward compatibility. At any given point we may drop or modify this feature. It may be
because we can no longer maintain the code, or perhaps a security issue is found in the
version of the code that we ship with, etc.
3. Please always remember that we are now bundling a static set of code for handling
x509 formats. You are taking a possible security risk by code that could be outdated.
Please always do your own research, and if possible, please notify us if the bundled
code needs to be updated. Unless you know what you are doing, it is not recommended
that you enable this feature.
4. Please note that because we imported the code from go 1.22's src/crypto/x509,
it has some go1.20-isms in its code. Therefore you will not be able to use the
`jwx_secp256k1_pem` tag to enable secp256k1 key PEM handling against codebases
that are built using go 1.19 and below (the build will succeed, but the feature
will be unavailable).
5. We have no plans to include more curves this way. One is already one too many.
* [jwe] Fixed a bug when using encryption algorithms involving PBES2 along with the
jwx.WithUseNumber() global option. Enabling this option would turn all values
stored in the JSON content to be of type `json.Number`, but we did not account for
it when checking for the value of `p2c` header, resulting in a conversion error.
