This is the last minor JJWT release branch that will support Java 7.

Any necessary emergency bug fixes will be fixed in subsequent 0.13.x patch releases, but all new development, including Java 8 compatible changes, will be in the next minor (0.14.0) release.

All future JJWT major and minor versions ( 0.14.0 and later) will require Java 8 or later.

This release contains a single change:

• The previously private JacksonDeserializer(ObjectMapper objectMapper, Map<String, Class<?>> claimTypeMap) constructor is now public for those that want register a claims type converter on their own specified ObjectMapper instance. Thank you to @kesrishubham2510 for PR #972. See Issue 914.

Full Changelog: https://github.com/jwtk/jjwt/compare/0.12.7...0.13.0

This patch release:

• Adds a new Maven BOM! This is useful for multi-module projects. See Issue 967.

• Allows the JwtParserBuilder to have empty nested algorithm collections, effectively disabling the parser's associated feature:

  • Emptying the zip() nested collection disables JWT decompression.
  • Emptying the sig() nested collection disables JWS mac/signature verification (i.e. all JWSs will be unsupported/rejected).
  • Emptying either the enc() or key() nested collections disables JWE decryption (i.e. all JWEs will be unsupported/rejected)

  See Issue 996.

• Fixes bug 961 where JwtParserBuilder nested collection builders were not correctly replacing algorithms with the same id.

• Ensures a JwkSet's keys collection is no longer entirely secret/redacted by default. This was an overzealous default that was unnecessarily restrictive; the keys collection itself should always be public, and each individual key within should determine which fields should be redacted when printed. See Issue 976.

• Improves performance slightly by ensuring all jjwt-api utility methods that create *Builder instances (Jwts.builder(), Jwts.parserBuilder(), Jwks.builder(), etc) no longer use reflection.

  Instead,static factories are created via reflection only once during initial jjwt-api classloading, and then *Builders are created via standard instantiation using the new operator thereafter. This also benefits certain environments that may not have ideal ClassLoader implementations (e.g. Tomcat in some cases).

  NOTE: because this changes which classes are loaded via reflection, any environments that must explicitly reference reflective class names (e.g. GraalVM applications) will need to be updated to reflect the new factory class names.

  See Issue 988.

• Upgrades the Gson dependency to 2.11.0

• Upgrades the BouncyCastle dependency to 1.78.1

• @sigpwned made their first contribution in https://github.com/jwtk/jjwt/pull/968
• @TheMrMilchmann made their first contribution in https://github.com/jwtk/jjwt/pull/979
• @atanasg made their first contribution in https://github.com/jwtk/jjwt/pull/974

Full Changelog: https://github.com/jwtk/jjwt/compare/0.12.6...0.12.7

This patch release:

• Ensures that after successful JWS signature verification, an application-configured Base64Url Decoder output is used to construct a Jws instance (instead of JJWT's default decoder). See https://github.com/jwtk/jjwt/issues/947.
• Fixes a decompression memory leak in concurrent/multi-threaded environments introduced in 0.12.0 when decompressing JWTs with a zip header of GZIP. See https://github.com/jwtk/jjwt/issues/949.
• Upgrades BouncyCastle to 1.78 via https://github.com/jwtk/jjwt/pull/941
• Usees Acsiidoc as README format by @bdemers in https://github.com/jwtk/jjwt/pull/777
• Allows using GenericSecret for HmacSHA* algorithms by @mnylen in https://github.com/jwtk/jjwt/pull/935
• Enables JWE arbitrary content compression by @mnylen in https://github.com/jwtk/jjwt/pull/937

• @mnylen made their first contribution in https://github.com/jwtk/jjwt/pull/935

Full Changelog: https://github.com/jwtk/jjwt/compare/0.12.5...0.12.6

This release fixes issue #916 and ensures that builders' NestedCollection changes are applied to the collection immediately as mutation methods are called, no longer requiring application developers to call .and() to 'commit' or apply a change. For example, prior to this release, the following code did not apply changes:

JwtBuilder builder = Jwts.builder();
builder.audience().add("an-audience"); // no .and() call
builder.compact(); // would not keep 'an-audience'

Now this code works as expected and all other NestedCollection instances like it apply changes immediately (e.g. when calling .add(value)).

However, standard fluent builder chains are still recommended for readability when feasible, e.g.

Jwts.builder()
    .audience().add("an-audience").and() // allows fluent chaining
    .subject("Joe")
    // etc...
    .compact()

These same notes are repeated in the CHANGELOG, and as always, project documentation is in the README.

Please allow 30 minutes from the time this announcement is published for the release to be available in Maven Central.

This is patch release completes 10 issues, with two especially noteworthy changes, and a number of other smaller bug fixes and enhancements.

1. The default Jackson deserializer will now reject duplicate JSON members by default in an attempt to be a little more strict at rejecting potentially malicious or malformed JSON. This is a default and can be overridden with a custom ObjectMapper if desired.
2. Password-based JWE encryption key algorithms (PBES2_HS256_A128KW, PBES2_HS384_A192KW and PBES2_HS512_A256KW) now enforce an upper bound (maximum) number of iterations allowed during decryption to mitigate against potential DoS attacks. Many thanks to Jingcheng Yang and Jianjun Chen from Sichuan University and Zhongguancun Lab for their work on this!

A number of other issues fixed: thread-safe ServiceLoader usage for dynamic JSON processor lookup, Android enhancements for JSON Reader APIs, fixed Elliptic Curve field element padding, and more. Please read the 0.12.4 CHANGELOG for full details of all of these changes, and as always, project documentation is in the 0.12.4 README.

Please allow 30 minutes from the time this announcement is published for the release to be available in Maven Central.

This is a minor patch release that address two issues:

1. The org.json dependency has been upgraded to 20231013 to address that library's CVE-2023-5072 vulnerability.

2. Empty custom claims values are (re-)enabled which was the behavior in <= 0.11.5. See Issue 858.

These same notes are repeated in the CHANGELOG, and as always, project documentation is in the README.

Please allow 30 minutes from the time this announcement is published for the release to be available in Maven Central.

This is a follow-up release to finalize the work in 0.12.1 that tried to fix a reflection scope problem on >= JDK 17. The 0.12.1 fix worked, but only if the importing project or application did not have its own module-info.java file.

This release removes that reflection code entirely in favor of a JJWT-native implementation, eliminating JPMS module (scope) problems on >= JDK 17. As such, --add-opens flags are no longer required to use JJWT.

The fix has been tested up through JDK 21 in a separate application environment (out of JJWT's codebase) to assert expected functionality in a 'clean room' environment in a project both with and without module-info.java usage.

Notes are in the CHANGELOG, and project documentation is in the README.

Please allow 30 minutes from the time this announcement is published for the release to be available in Maven Central.

This is a quick follow-up release from yesterday's 0.12.0 release that addresses a reflection issue on JDK 17. The fix has been tested up through JDK 21.

Notes are in the CHANGELOG, and project documentation is in the README.

Please allow 30 minutes for the release to be available in Maven Central.

It is finally here! This release includes full support for JSON Web Encryption (JWE), JSON Web Keys (JWK), JSON Web Key Thumbprints, JSON Web Key Thumbprint URIs, and so, so much more.

This is the culmination of hundreds of hours worth of work and testing, and we're glad to finally release it. However, please note:

This is our first-ever breaking change release. While we tried hard to minimize the breakages, some were just necessary in preparation for 1.0 and to finalize all JWT RFC features. If you are not partial to fixing changes when upgrading a library, we strongly encourage you to wait until the 1.0 release.

Please pay particular attention to the CHANGELOG listing breaking changes.

Full documentation is available in the README.