Shade JSON Smart dependency

[Thomas Zimmermann]

The currently used net.minidev:json-smart:2.3 has a transitive dependency on asm, which is very widely used and therefore prone to dependency conflicts. To lend some credibility to this statement, the spring framework embeds it's bytecode manipulation dependencies directly for exactly this reason.

As an example for a library in a similiar situation to oauth2-oidc-sdk, jose4j uses json-simple (which has no dependencies) internally. This way, users of jose4j are free to use any JSON library or version of asm. This really is a shortcoming of the JDK, but it's better for the complexity to live in libraries instead of user code.

Since json-smart is used everywhere in the code (and probably public API as well, I haven't checked), this would need a longer deprecation cycle. But I think the added flexibility makes it worthwhile.

[Vladimir Dzhuvinov]

I wonder why the ASM dependency isn't made optional, or part of a more "feature-full" JSON Smart. We only use the core classes of JSON Smart, no ASM stuff.

[Yavor Vasilev]

About ASM this might help: https://bitbucket.org/connect2id/nimbus-jose-jwt/issues/239/switch-to-other-json-library#comment-53099123

[David Moten]

We only use the core classes of JSON Smart, no ASM stuff.

So the ASM dependency can be excluded without problem?

[Vladimir Dzhuvinov]

Yes, it can be excluded. This SDK and the JWT lib don’t use any ASM features.

[Vladimir Dzhuvinov]

PS: The most recent builds (7.1.*) use JSON Smart 1.3.1 which has no ASM dependency, so there is no need to exclude it specifically now.

[David Moten]

Excellent, thanks Vladimir!

[Martin Burchard]

Just seen this… why have you downgraded JSON Smart from 2.3 to 1.3.1?

Other Libraries depend on on 2.3… See me other comment

[Yavor Vasilev]

Well, a bunch of people wanted no ASM, one way to accommodate that was by downgrading to 1.3.1 which has no ASM.

To reiterate, ASM is not required by this SDK.

In today’s 7.4 the dep range was brought back.

Anyone feel free to set their own preferred JSON Smart version.

version 7.4 (2020-04-20)
    * Updates JAR support in AuthorizationRequest and AuthenticationRequest to
      draft-ietf-oauth-jwsreq-21.
    * Restored dep range net.minidev:json-smart:[1.3.1,2.3]
    * Bumps to com.nimbusds:nimbus-jose-jwt:8.14.1
    * Bumps optional OpenSAML dep to 3.4.5

Hope this helps (though no permanent ASM solution).

[Yavor Vasilev]

Shade JSON Smart (similarly to Nimbus JOSE+JWT 9.0), target for release 10.0.

[Yavor Vasilev]

Issue #337 was marked as a duplicate of this issue.

[Emond Papegaaij]

When do you expect to release 10.0? The current situation makes it impossible for us to upgrade to 9.x. We rely heavily on custom JWTs in our codebase and use Nimbus JOSE+JWT for that. We need to be able to pass OAuth2/OIDC related values back and forth via JWTs. The current situation breaks this completely. For example, when we put an AMR in an access token (JWTClaimsSet) it now shows up as {} because the JSONAware interface is no longer picked up and the AMR is seen as a generic Object. We also have issues with several methods that take or return JSONObject. We constantly need to convert back and forth between JSONObject and Map<String, Object> and JSONArray and List<Object>.

[Christopher Lamb]

It is 2023, and the current latest oauth2-oidc-sdk is 10.13.2.

We are experimenting with nimbus-jose-jwt and oauth2-oidc-sdk.10.13.2, and see that they use two different json libraries.

As far as I can make out:

nimbus-jose-jwt-9.31 uses gson. Older versions used json-smart.

oauth2-oidc-sdk.10.13.2 still uses json-smart.

json-smart 2.4.8 or below (inc 1.3) has CVEs, so we have tested with version 2.5

Testing oauth2-oidc-sdk.10.13.2 + json-smart.2.5 with ASM and accessors-smart excluded from the classpath throws java.lang.ClassNotFoundException, indicating that accessors-smart and ASM are required.

Are there plans to move oauth2-oidc-sdk to gson soon?

[Yavor Vasilev]

Hi Christopher,

The Nimbus JOSE+JWT lib uses GSon internally and it’s shaded to prevent dep conflicts.

The OIDC SDK still uses JSON Smart. In contrast to the JWT lib, here the JSON Smart classes JSONObject and JSONArray are much more widely used in the lib’s public APIs. A switch to Map<String,Object and List<Object> as it was done in the JWT lib will likely break many more projects and much more code, including integrations of our Connect2id server. For this reason this switch was put on hold.

[Christopher Lamb]

Hi Yavor

Thanks for you rapid answer.

Shading was a new concept to me: It took a while to click that despite imports like “com.google.gson.Gson" the Gson code being called is from the shaded package within the JOSE+JWT jar.

Changing libraries is a task not to be underestimated, especially if public APIs must change…. You are dammed if you, and dammed if you don’t.

We started our OIDC journey with Nimbus JOSE+JWT. One of the key attractions was that it had almost no dependencies. Dependencies and transitive dependencies are always a pain, especially those with CVEs.

We then started implementing an OIDC client, and looked closer at the OIDC SDK, but were surprised that it had many more dependencies than the JOSE+JWT, including stuff like ASM that we had kicked out of our architecture with joy some years ago.