Multiple JWK Set support

The purpose of this release is to add support for multiple JWK Sets. Through the use of the new keyfunc.GetMultiple function, package users can now specify multiple remote JWK Set resources and produce one jwt.Keyfunc.

It is not recommended to use the RefreshUnknownKID field on keyfunc.Option field when using multiple JWK Sets.

Thank you to @aklinkert for this feature request!

Related issues:

• #72

Related pull requests:

• #78

Allow manual refresh of a remote JWKS resource

The purpose of this release is to add a method to manually refresh the remote JWKS resource. This can bypass the rate limit, if the option is set.

Please see the new .Refresh method.

Related issues:

• #40

Related pull requests:

• #76

Allow JWKS JSON to be made into Given Keys

The purpose of this release is to add a function that can transform raw JWKS JSON into map[string]keyfunc.GivenKey. This supports the use case where JWKS JSON is given, but a remote resource is also needed via keyfunc.Get. The map[string]keyfunc.GivenKey can be passed via the GivenKeys field in the keyfunc.Options argument.

Thank you to @sean-rn for this contribution!

Related issues:

• #73

Related pull requests:

• #74
• #75

Specify signing algorithm for given keys

The purpose of this release is to allow package users to specify which signing algorithms in JWT headers are required for which given keys. Keys from a remote JWK Set had their algorithm checked in release 1.5.2. For discussion, please see the related issue.

Thank you to our new contributor, @sean-rn!

Please note the following functions have been deprecated and replaced:

• NewGivenCustom --> NewGivenCustomWithOptions
• NewGivenECDSA --> NewGivenECDSAWithOptions
• NewGivenEdDSA --> NewGivenEdDSAWithOptions
• NewGivenHMAC --> NewGivenHMACWithOptions
• NewGivenRSA --> NewGivenRSAWithOptions

This is a consequence of not providing options for given keys in the initial implementation.

Related issues:

• #69

Related pull requests:

• #70
• #71

Handle invalid ECDSA curve in JWK

The purpose of this pull request is to add a a default switch case for ECDSA curve selection. Previously, if an invalid or empty crv JWK parameter was given for an ECDSA key, there would be a nil pointer dereference panic. You can find more information about valid crv ECDSA JWK parameters in this RFC: https://www.rfc-editor.org/rfc/rfc7518#section-6.2.1.1

Thank you to our new contributor, @btoews!

Related pull requests:

• #66
• #67

Confirm JWK algorithm

The purpose of this release is to confirm the alg parameter in a JWK matches the alg in a JWT's header before returning that JWK's public key for signature verification. For discussion, please see the related issue.

Thank you, @sermojohn for opening this issue!

Related issues:

• #62

Related pull requests:

• #63

JSON Web Keys restricted by "use" parameter

The purpose of this PR is to restrict what keys are returned by the .Keyfunc method based on their JWK's "use" parameter's value.

Two new keyfunc.Options fields have been added:

• JWKUseWhitelist
• JWKUseNoWhitelist

The default behavior of this package has changed to enhance the security of this package. The new default behavior will return keyfunc.ErrJWKUseWhitelist if a JWT has been signed by a parsed JWK whose "use" parameter value is not "sig", the empty string "", or a JWK with no "use" parameter. If your use case involved a custom JWK "use" parameter value, you will need to specify your custom value(s) in the new JWKUseWhitelist field on the keyfunc.Options data structure.

The previous default behavior would not cause an error if a JWK's "use" parameter's value was "enc", which would be an improper JWK for signing a JWT. See https://tools.ietf.org/html/rfc7517#section-4.2

Thank you to our new contributor, @trevorlyman!

Relevant pull requests:

• #57
• #54

Relevant issues:

• #53

Check HTTP status code

The purpose of this release is to change the default behavior of the ResponseExtractor to use the keyfunc.ResponseExtractorStatusOK function. Changing the default behavior is being treated as a bug fix. This release also fixes a bug within keyfunc.ResponseExtractorStatusOK, which didn't close the HTTP response body (resource leak) that only affected v1.3.0, which is now retracted in the go.mod.

This release also contains:

• A new function, ResponseExtractorStatusAny. This is a helper function that uses the old behavior of ignoring the HTTP status code in when extracting the JWKS JSON from the response.
• A new method, .Len. This method returns the number of keys in the JWKS.

Relevant pull requests:

• #52

Relevant issues:

• #51
• #48

Add response extractor

Edit: This release has been retracted due to a bug in ResponseExtractorStatusOK not closing the response body. Please upgrade to v1.4.0.

The purpose of this release is to allow for custom HTTP response extractors. A response extractor is responsible for consuming an *http.Response and producing the raw JWK Set JSON. It is also responsible for closing the body of the *http.Response.

I plan on following up this release with v1.3.1 soon. This upcoming release will change the default behavior of how the package handles HTTP response codes, returning a non-nil error in cases such as a 500 HTTP response code.

New additions:

• keyfunc.Options has a new field named ResponseExtractor that, when provided, is responsible for the behavior described above.
• keyfunc.ResponseExtractorStatusOK is a helper function to fit into the ResponseExtractor field in keyfunc.Options.

Relevant pull requests:

• #50

Relevant issues:

• #49
• #48

Bump minimum Go version

The minimum Go version for release v1.2.1 should have been Go 1.16 since the functions to match the deprecated functions in io/ioutil were from that release.