Skip to content

Releases: vapor/jwt-kit

4.13.0 - Add customizable JSON encoders and decoders

18 Jul 00:46
9e929d9
Compare
Choose a tag to compare

Add new, fully source-compatible APIs to JWTSigners and JWTSigner which allow specifying custom JSON encoders and decoders. Also provides the JWTJSONEncoder and JWTJSONDecoder protocols, which allow using alternative JSON implementations.

Custom coders specified for a single JWTSigner affect token parsing and signing performed only by that signer. Custom coders specified on a JWTSigners object will become the default coders for all signers added to that object, unless a given signer already specifies its own custom coders.

The default encoding and decoding implementation provided for JWTUnixEpochClaim (of which ExpirationClaim (exp), IssuedAtClaim (iat), and NotBeforeClaim (nbf) are examples) has been adjusted to encode and decode its Date value directly, rather than performing the explicit conversion to and from a Double. This allows these claims to take advantage of the dateEncodingStrategy and dateDecodingStrategy specified on custom JSON coders. (It also gives a bit of the lie to the name JWTUnixEpochClaim, but it's public API, so I left it alone.)

The default coders in use remain the same: An encoder and decoder which use the .secondsSince1970 date encoding/decoding strategy. As such, neither the new support nor the change to Date-based claims affects how tokens are signed or verified unless custom coders with different strategies are specified (that being, after all, the original need which inspired these changes).

Finally, an .integerSecondsSince1970 date encoding and decoding strategy has been added to the public API for the benefit of interoperation with JWT implementations - such as that used by GitHub - which require the aforementioned date-based claims to specify values as an integer number of seconds. (As GitHub proves, while this is in violation of the definition of NumericDate given by RFC 7519 § 2, which explicitly permits floating-point values, it nonetheless appears in the wild.)

This is a semver-minor release, as it adds new public API (although it has been careful to fully retain source compatibility, at the cost of a goodly amount of silly-looking repetition in the implementation - please, do not ask me if I know what default parameter values are! 😂).

AppleIdentityToken: Adds `real_user_status` claim

05 Jul 14:15
dd3fe31
Compare
Choose a tag to compare
This patch was authored by @qalandarov and released by @0xTim.

Adds the missing real_user_status claim which helps detecting if the user is likely a real person. Closes #88

Improve JWKS `find(identifier:type:)`

05 Jul 13:12
78b292d
Compare
Choose a tag to compare
This patch was authored by @nnsnodnb and released by @0xTim.

Update JWKS find(identifier:type:) to use better Swift algorithms for matching

Add optional org_id field to AppleIdentityToken

15 Jun 18:28
8b3a69c
Compare
Choose a tag to compare
This patch was authored by @RanLearns and released by @gwynne.

Motivation and Reasoning

When working with Managed Apple IDs (schools and business) there can be a need to decode an additional field of a user's org_id when they sign in.

Update the vendored BoringSSL

02 Jun 18:14
268cdf5
Compare
Choose a tag to compare
This patch was authored and released by @gwynne.

Update the vendored BoringSSL to the latest. This also brings in the latest updates to the vendoring scripts themselves from upstream, updates CI (what? In a PR from Gwynne? Say it ain't so!), and bumps the minimum Swift version to 5.6 to be in line with Vapor.

JWS/x5c support with ES256 keys

26 Mar 15:28
ef12bdf
Compare
Choose a tag to compare
This patch was authored by @WFT and released by @gwynne.

Verify JWS tokens using x5c header parameters (ES256 keys only right now).

This PR is based on @0xTim’s work in #75, but uses the X509_STORE/X509_verify_cert API rather than re-implementing that logic in Swift.

Details on x5c: https://www.rfc-editor.org/rfc/rfc7515#section-4.1.6

Add support for Octet Key Pairs with the EdDSA algorithm using the ED25519 curve

19 Jan 20:00
dcd78f0
Compare
Choose a tag to compare
This patch was authored by @mgratzer and released by @0xTim.

This implements support for Octet Key Pairs (RFC8037) with the EdDSA algorithm and ED25519 curves. It closes #50.

Add `JWTSigner.unsecuredNone`

02 Aug 11:04
87ce13a
Compare
Choose a tag to compare
This patch was authored by @baarde and released by @0xTim.

This PR adds support for the "none" algorithm described in Section 6 of RFC 7519.

Add experimental watchOS support

08 Jul 23:50
aa7d9cd
Compare
Choose a tag to compare
This patch was authored by @thebabufrik and released by @0xTim.

Adds experimental watchOS support by providing a watchOS platform to match the minimum version of the dependencies so it will compile

Fix Base64URL JWK conversion for ECDSA keys

14 Jun 18:27
718e94f
Compare
Choose a tag to compare
This patch was authored by @MFranceschi6 and released by @0xTim.

Fixes an issue where JWTKit does not follow RFC7517

An jwk representing an ecdsa key is represented with the parameters x and y in base64url-encoded form. Previously the parameters were converted as Base64 encoded instead of Base64URL encoded.

Adds new APIs for converting to and from base64 URL encoded data