Allow using custom ObjectMapper for JWTParser

[michael4screen]

Checklist

• I have looked into the Readme and Examples, and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

I would like to use my custom ObjectMapper with the JWTParser.
I'm using kotlin and the default ObjectMapper is not equipped with the jackson kotlin module.
I see there is a constructor JWTParser(ObjecMapper objectmapper) but unfortunately its package private, so I have no possibility to use it.

Describe the ideal solution

Make the JWTParser(ObjecMapper objectmapper) constructor protected/public

Alternatives and current workarounds

As a current workaround I'm working with @JsonProperty annotations on my POJOs to make it work with the default ObjectMapper.

Additional context

No response

[jimmyjames]

👋 hi @michael4screen, thanks for the issue and info. Any chance you could provide a little sample to demonstrate the issue? The constructor is not public because we don't want to expose internal dependencies as part of the public API. Perhaps there's a different way we can help get this working for you without exposing the Jackson dependency as part of the public API.

[adam-gray]

Hi @jimmyjames, I'd like to be able to configure the ObjectMapper used in JWTParser to be able to use the Afterburner module for performance testing. Registering the module is a trivial change.

If a configurable ObjectMapper isn't in the cards, it might be worth adding the Afterburner module regardless. Let me know if I should open a new issue for that, as I don't want to take away from @michael4screen's need to reconfigure ObjectMapper for reasons other than performance.

[eric-givzey]

Hello,

I would also find this to be useful, for a different reason. I'm using this library to embed objects with java.util.Optional properties in a JWT payload. Jackson cannot deserialize these objects unless the ObjectMapper has a com.fasterxml.jackson.datatype.jdk8.Jdk8Module registered on it.

To work around this, I needed to subclass com.auth0.jwt.impl.JWTParser to expose the JWTParser(ObjectMapper mapper) constructor, and since that constructor is package-private, I needed to put my own subclass in the com.auth0.jwt.impl package. And since the JWTDecoder class is final and its constructors are package-private, I also subclassed com.auth0.jwt.JWT in order to be able to construct a JWTDecoder with the JWTParser subclass.

Here are code samples, modified to change names:

package com.auth0.jwt.impl;

import com.fasterxml.jackson.databind.ObjectMapper;

public class CustomJWTParser extends JWTParser {
    public CustomJWTParser(ObjectMapper mapper) {
        super(mapper);
    }
}

package com.auth0.jwt;

import com.auth0.jwt.exceptions.JWTDecodeException;
import com.auth0.jwt.impl.CustomJWTParser;
import com.auth0.jwt.interfaces.DecodedJWT;
import com.fasterxml.jackson.databind.ObjectMapper;

public class CustomJWT extends JWT {
    private final CustomJWTParser parser;

    public CustomJWT(ObjectMapper mapper) {
        parser = new CustomJWTParser(mapper);
    }

    @Override
    public DecodedJWT decodeJwt(String token) throws JWTDecodeException {
        // Since parser is a field on superclass, need to also override this method to
        // use subclass's field
        return new JWTDecoder(parser, token);
    }
}

Then, as an (extremely simplified) example of usage (in reality, I access the subclasses from a jakarta.ws.rs.ext.MessageBodyReader and determine output types based on the Class<Object> type, Type genericType parameters to readFrom):

package com.example.model;

import java.util.Optional;
import jakarta.validation.constraints.NotEmpty;
import com.fasterxml.jackson.annotation.JsonInclude;
import static com.fasterxml.jackson.annotation.JsonInclude.Include.NON_ABSENT;

public record ExampleData(
        @NotEmpty String tenantId,
        @NotEmpty String value,
        @JsonInclude(NON_ABSENT) Optional<Long> createdAt) {
}

...
package com.example.util;

import java.util.List;
import com.auth0.jwt.CustomJWT;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.example.model.ExampleData;

class JwtDataHandler {
    public static final String DATA_CLAIM = "dat";
    public List<ExampleData> extractData(ObjectMapper mapper, String jwt) {
        Claim claim = new CustomJwt(mapper).decodeJwt(jwt).getClaim(DATA_CLAIM);
        return claim.asList(ExampleData.class);
    }
}

Without the use of the custom subclasses, I would not be able to use Claim.asList or Claim.as to deserialize the claim to my data types.

---

The constructor is not public because we don't want to expose internal dependencies as part of the public API

That's very understandable, but as-is, Claim is a rather leaky abstraction over JsonNode; I have to be aware that Jackson is being used to deserialize the data in order to correctly deserialize. Perhaps an alternative could be allowing the Claim to return the raw JSON string so the client can deserialize it using their own ObjectMapper (or even a different JSON parsing library), similar to how JWTCreator.Builder.withPayload(String) accepts already-generated JSON.