This patch release includes various changes listed below.

This release makes two behavioral changes to JJWT's default Jackson `ObjectMapper` parsing settings:

1. In the interest of having stronger standards to reject potentially malformed/malicious/accidental JSON that could

have undesirable effects on an application, JJWT's default `ObjectMapper `is now configured to explicitly reject/fail

parsing JSON (JWT headers and/or Claims) if/when that JSON contains duplicate JSON member names.

For example, now the following JSON, if parsed, would fail (be rejected) by default:

```json

{

"hello": "world",

"thisWillFail": 42,

"thisWillFail": "test"

}

```

Technically, the JWT RFCs _do allow_ duplicate named fields as long as the last parsed member is the one used

(see [JWS RFC 7515, Section 4](https://datatracker.ietf.org/doc/html/rfc7515#section-4)), so this is allowed.

However, because JWTs often reflect security concepts, it's usually better to be defensive and reject these

unexpected scenarios by default. The RFC later supports this position/preference in

[Section 10.12](https://datatracker.ietf.org/doc/html/rfc7515#section-10.12):

Ambiguous and potentially exploitable situations

could arise if the JSON parser used does not enforce the uniqueness

of member names or returns an unpredictable value for duplicate

member names.

Finally, this is just a default, and the RFC does indeed allow duplicate member names if the last value is used,

so applications that require duplicates to be allowed can simply configure their own `ObjectMapper` and use

that with JJWT instead of assuming this (new) JJWT default. See

[Issue #877](https://github.com/jwtk/jjwt/issues/877) for more.

[Custom Claim Types](https://github.com/jwtk/jjwt#json-jackson-custom-types) (for example, a Claim that should be

unmarshalled into a POJO), and the JSON for that POJO contained a member that is not represented in the specified

class, Jackson would fail parsing by default. Because POJOs and JSON data models can sometimes be out of sync

due to different class versions, the default behavior has been changed to ignore these unknown JSON members instead

of failing (i.e. the `ObjectMapper`'s `DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES` is now set to `false`)

by default.

Again, if you prefer the stricter behavior of rejecting JSON with extra or unknown properties, you can configure

`true` on your own `ObjectMapper` instance and use that instance with the `Jwts.parser()` builder.

implementations of JJWT interfaces (e.g. JSON parsers, etc). See

[Issue #873](https://github.com/jwtk/jjwt/issues/873) and its documented fix in

[PR #893](https://github.com/jwtk/jjwt/pull/892).