Table of Contents

Breaking Changes

List of changes in each version that breaks backward compatibility from a previous version.

Version 2.6

Updating the JOSE/JWT library to the latest upstream version closed several weaknesses in token validation. Each one makes the library reject tokens it used to accept, so an application that relied on the old behaviour has to be adjusted.

  • Unsigned tokens (alg=none) are no longer accepted by default. Pass TJOSEAlgorithmId.None to SetExpectedAlgorithms if you really need to accept them.

  • Token parts must be valid base64url. Padding, whitespace, line breaks and the + and / characters of standard base64 are rejected. Set TBase64.StrictURLDecoding to False to interoperate with an issuer that emits non-conforming tokens.

  • A PEM key is rejected as an HMAC shared secret. A secret starting with -----BEGIN now raises an exception.

  • The signing key is validated in TJOSE.Verify, TJOSE.DeserializeCompact and the producer API. A key too short for the chosen algorithm is now rejected.

  • An expired token is rejected by a consumer that has been alive for a while, which previously evaluated tokens against the time of its first validation.

  • A token is now expired at the exact second of its exp claim, as the JWT standard specifies, instead of one second later. This includes the allowed clock skew: a token that expired 2 seconds ago is rejected with a skew of 2 seconds and accepted with 3.

  • Some validation error messages changed wording, and the invalid-signature message no longer includes the signature. Sparkle's JWT middleware returns these messages in the 401 response body, so adjust any code that compares them literally.

  • A token carrying an aud claim is no longer rejected when the consumer has no expected audience configured and did not ask for the audience to be validated.

  • TJSONUtils.GetJSONValue returns whole numbers as Int64 instead of Double. Code that read the result as a floating point value has to be adjusted.