Skip to content

Releases: MicahParks/jwkset

v0.11.0

20 Sep 19:50
0d285de

Choose a tag to compare

The purpose of this release is to allow JWK Sets to be processed even if not every key is a supported type. An example of an unsupported key type would be Ed448.

Please see the new RequireSupportedKeys option on HTTPClientStorageOptions.

Relevant issues:

Relevant pull requests:

v0.10.0

15 Sep 21:15
6fab088

Choose a tag to compare

The purpose of this release is to automatically extract the certificate's key usage in the jwkset CLI tool. This has not been added to the library or website yet.

Relevant issues:

Relevant pull requests:

Commits outside of pull requests (I will add branch protection now):

v0.9.6

19 May 21:50
3835d6d

Choose a tag to compare

The purpose of this release is to have a more complete implementation of the strict padding toggle feature. There should no longer be an error when comparing Base64 URL encoded integers with their Base64 raw URL equivalents when strict padding is off.

Releavant issues:

Relevant pull requests:

v0.9.0

02 Apr 21:12
fa0fbd5

Choose a tag to compare

The purpose of this release is to add the Storage field back to the HTTPClientStorageOptions data structure. It was removed in v0.6.0 because I thought it was unused.

Breaking changes:

  • Implementations of the Storage interface now require a KeyReplaceAll method.

Relevant issues:

Relevant pull requests:

Change function parameter type

16 Jan 13:33
437c67f

Choose a tag to compare

The purpose of this release is to change a function parameter from type from *url.URL to string for convenience.

Breaking changes:

  • The NewStorageFromHTTP function accepts a string instead of a *url.URL.

Relevant issues:

Relevant pull requests:

Fix potential race condition

10 Jan 01:33
c8d5ec7

Choose a tag to compare

The purpose of this release is to fix a potential race condition.

Breaking changes:

  • No breaking API changes.
    • Allow for JWK with the same Key ID kid to be present in the set.

Relevant pull requests:

v0.6.0

09 Jan 13:20
01db49a

Choose a tag to compare

The purpose of this release is to fix a bug pointed out by @rohitkoul in #7 (comment). There is a bug in the refresh goroutine related to key replacement.

The project's provided HTTP client's local JWK Set cache should do a full replacement when the goroutine refreshes the remote JWK Set. The current behavior is to overwrite or append. This is a security issue for use cases that utilize the provided auto-caching HTTP client and where key removal from a JWK Set is equivalent to revocation.

Regardless of this bug, please note that removing a key from a JWK Set does not equate to instant revocation for most use cases as it takes time for JWK Set updates to propagate to all clients.

Breaking changes:

  • Removed Storage field from the HTTPClientStorageOptions data structure.

Relevant issues:

Relevant pull requests:

Less strict validation

12 Mar 00:10
7091ac8

Choose a tag to compare

The purpose of this release is to use less strict validation for JWK. This will allow users to work with non-RFC compliant JWK Sets for small padding mistakes.

Two padding related reasons for this are:

  1. Mandatory leading padding for ECDSA JWK parameters.
  2. A common mistake adding leading padding to RSA JWK parameter "n".

For padding specifically, this project is only comparing integers after they are parsed from Base64 raw URL encoding by default. To turn on strict validation, there will be a new field on jwkset.ValidateOptions named StrictPadding.

An example for 1 would be a bug in this project were mandatory leading padding was absent: #18

An example for 2 would be a Firebase service that was reported to be incompatible with this project: #23

Relevant issues:

Relevant pull requests:

v0.5.13

04 Mar 22:54
a0de971

Choose a tag to compare

The purpose of this release is to correctly pad EC JWK parameters with leading zeros where required by RFC 7518.

For "x" and "y":

The length of this octet string MUST be the full size of a coordinate for the curve specified in the "crv" parameter. For example, if the value of "crv" is "P-521", the octet string must be 66 octets long.

For "d":

The length of this octet string MUST be ceiling(log-base-2(n)/8) octets (where n is the order of the curve).

This is to bring the project into RFC compliance with RFC 7518 Section 6.2.1.2, 6.2.1.3, and 6.2.2.1.

Relevant issues:

What's Changed

Full Changelog: v0.5.12...v0.5.13

jwksetinfer tool multi-PEM bug

25 Jan 03:06
ece0023

Choose a tag to compare

A bug in the cmd/jwksetinfer tool caused multiple PEM file inputs to only output the final PEM key as a JWK Set. This is because the metadata wasn't being passed in and the all key IDs were the same empty string.

Thank you @aarnaud for discovering the bug and fixing it!

Relevant pull requests: