v2.1.3

What's Changed

• Remove non-applicable comment by @lestrrat in #1223
• Bump golang.org/x/crypto from 0.28.0 to 0.29.0 by @dependabot in #1232
• Change random big value to math.MaxInt by @lestrrat in #1242

Full Changelog: v2.1.2...v2.1.3

v3.0.0-alpha1

This is the initial release of the v3 line.

See Changes-v3.md

v2.1.2

What's Changed

• Bump golang.org/x/crypto from 0.25.0 to 0.26.0 by @dependabot in #1168
• Fix document of how to parse PEM via CLI by @kg0r0 in #1174
• Wrap the errors from functions called within ParseRequest by @lestrrat in #1176
• V2 modernize workflows by @lestrrat in #1182
• Dependabot fixes for v2 by @lestrrat in #1183
• Use variable by @lestrrat in #1186
• Bump golang.org/x/crypto from 0.26.0 to 0.27.0 by @dependabot in #1177
• Bump golangci/golangci-lint-action from 6.1.0 to 6.1.1 by @dependabot in #1199
• Bump golang.org/x/crypto from 0.27.0 to 0.28.0 by @dependabot in #1208
• update comments to include iat by @cscochris in #1216

New Contributors

• @kg0r0 made their first contribution in #1174
• @cscochris made their first contribution in #1216

Full Changelog: v2.1.1...v2.1.2

v2.1.1

v2.1.1 Jul 28 2024
  * Update minimum required go version to go 1.20
  * Update tests to work on 32-bit systems.
  * [jwa] Add RSA_OAEP_384 and RSA_OAEP_512
  * [jwa] `jwa.SignatureAlgorithm` now has a `IsSymmetric` method.
  * [jwa] Add `jwa.RegisterSignatureAlgorithmOptions()` to register new algorithms while
    specifying extra options. Currently only `jwa.WithSymmetricAlgorithm()` is supported.
  * [jws] Clearly mark `jws.WithHeaders()` as deprecated

v1.2.30

v1.2.30 28 Jul 2024
  * Update minimum required go version to 1.20
  * Update tests so that they work on 32-bit systems

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.

    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.

v2.0.21

v2.0.21 07 Mar 2024

[Security]

• [jwe] Added jwe.Settings(jwe.WithMaxDecompressBufferSize(int64)) to specify the
  maximum size of a decompressed JWE payload. The default value is 10MB. If you
  are compressing payloads greater than this and want to decompress it during
  a call to jwe.Decrypt, you need to explicitly set a value large enough to
  hold that data.

  The same option can be passed to jwe.Decrypt to control this behavior on
  a per-message basis.

• [jwe] Added documentation stating that jwe.WithMaxBufferSize option will be
  renamed in future versions, i.e. v3

v1.2.29

v1.2.29 07 Mar 2024

[Security]

• [jwe] Added jwe.Settings(jwe.WithMaxDecompressBufferSize(int64)) to specify the
  maximum size of a decompressed JWE payload. The default value is 10MB. If you
  are compressing payloads greater than this, you need to explicitly set it.

  Unlike in v2, there is no way to set this globally. Please use v2 if this is required.

v2.0.20

v2.0.20 20 Feb 2024

[New Features]

• [jwe] Added jwe.Settings(WithMaxBufferSize(int64)) to set the maximum size of
  internal buffers. The default value is 256MB. Most users do not need to change
  this value.
• [jws] Allow jws.WithCompact() and jws.WithJSON() to be passed to jws.Parse() and
  jws.Verify(). These options control the expected serialization format for the
  JWS message.
• [jwt] Add jwt.WithCompactOnly() to specify that only compact serialization can
  be used for jwt.Parse(). Previously, by virtue of jws.Parse() allowing either
  JSON or Compact serialization format, jwt.Parse() also alloed JSON serialization
  where as RFC7519 explicitly states that only compact serialization should be
  used. For backward compatibility the default behavior is not changed, but you
  can set this global option for jwt: jwt.Settings(jwt.WithCompactOnly(true))

[Miscellaneous]

• Internal key conversions should now allow private keys to be used in place of
  public keys. This would allow you to pass private keys where public keys are
  expected.

v2.0.19

v2.0.19 09 Jan 2024
[New Features]
  * [jws] Added jws.IsVerificationError to check if the error returned by `jws.Verify`
    was caused by actual verification step or something else, for example, while fetching
    a key from datasource

[Security Fixes]
  * [jws] JWS messages formated in full JSON format (i.e. not the compact format, which
    consists of three base64 strings concatenated with a '.') with missing "protected"
    headers could cause a panic, thereby introducing a possiblity of a DoS.

    This has been fixed so that the `jws.Parse` function succeeds in parsing a JWS message
    lacking a protected header. Calling `jws.Verify` on this same JWS message will result
    in a failed verification attempt. Note that this behavior will differ slightly when
    parsing JWS messages in compact form, which result in an error.