Releases: MicahParks/jwkset
v0.11.0
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
v0.9.6
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
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
Storageinterface now require aKeyReplaceAllmethod.
Relevant issues:
Relevant pull requests:
Change function parameter type
Fix potential race condition
v0.6.0
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
Storagefield from theHTTPClientStorageOptionsdata structure.
Relevant issues:
Relevant pull requests:
Less strict validation
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:
- Mandatory leading padding for ECDSA JWK parameters.
- 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
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
- Required leading zeros in ECDSA keys by @MicahParks in #19
Full Changelog: v0.5.12...v0.5.13