Bug Report: Payara Micro Requires JTI Despite Spec being Optional/FISH-6397

[tdevfeeds]

Description

---

We're evaluating Payara Micro v5 and migrating to OAuth 2. When running our MP prototype, it is unable to verify the JWT token and gives a 401 error due to missing JTI claim. This claim is optional in the spec.

It appears as though the JTI was required at one point in the MP-JWT spec as noted by the commenter here: #4269 (comment). This is verified by looking at this version of the MP-JWT spec. However, the 2.0 version of this document now say it is "recommended" which align with the JWT spec.

Expected Outcome

JWT is verifiable without JTI claim. JTI is not required.

Current Outcome

JWT verification fails at fish.payara.microprofile.jwtauth.jwt.JwtTokenParser.verifyAndParseSignedJWT(). The root cause appears to be

Payara/appserver/payara-appserver-modules/microprofile/jwt-auth/src/main/java/fish/payara/microprofile/jwtauth/jwt/JwtTokenParser.java

Line 94 in 7680990

private final List<Claims> requiredClaims = asList(iss, sub, exp, iat, jti);

Stack trace is attached.

Steps to reproduce

We have a simple project with a resource that has one GET method and returns a "hello world" HTTP 200 response. The "system.properties" file is attached.

Attachments:

• mp-jwt_401_jti_stacktrace.txt
• system.properties.txt

Our HelloWorld Jersey code:

@ApplicationPath("/")
@DeclareRoles({"Foo.Read"})
@LoginConfig(authMethod = "MP-JWT", realmName = "jwt-jaspi")
public class JAXRSConfiguration extends Application {

    public JAXRSConfiguration() { }

    @Override
    public Set<Class<?>> getClasses() {
        final Set<Class<?>> classes = super.getClasses();
        final Set<Class<?>> newClasses = new HashSet<>();
        newClasses.addAll(classes);
        newClasses.add(FooResource.class);

        return newClasses;
    }
}

@Path("foo")
public class FooResource {
    @Inject private JsonWebToken principal;
   
    @GET
    @RolesAllowed("Foo.Read")
    public Response ping() {
        return Response.ok("ping").build();
    }
}

Environment

• Payara Micro v5.2.0022.2
• JDK 17.0.3_6
• Windows 10

[shub8968]

Hi, @tdevfeeds,

Thank you for bringing the issue to our cognizance. I have raised an internal JIRA FISH-6397 for it.

[smillidge]

Note 2.0 MP JWT spec also says.

[NOTE] MP JWT implementations may enforce that JWT tokens contain all the recommended headers and claims. The recommended headers and claims may become required in the future versions of the MP JWT specification.

So we are still compliant. We will evaluate the impact of changing this.

[tdevfeeds]

Can I get an update on what the Payara team decided on this internally?

It seems like the MP-JWT spec is vague enough to allow the Payara MP team make decisions that do not align with the JWT specification itself. I simply don't understand this.

After 15+ years with JavaEE, our team is now looking into Spring because of this issue which is unfortunate.

[shub8968]

Hi, @tdevfeeds.

You should raise this with the Microprofile Project. If you want immediate implementation, I recommend you consider Payara Enterprise.

[tdevfeeds]

I missed the notification of #6639 being potentially closed. I only created that one at the request of Luis Neto, whom I met at DevNexus 2024. I also spoke with Emily Jiang and someone else at the Jakarta MP booth about this issue. When I mentioned that we may have to switch to Spring because of this, all three told me not to.

I'm finding it hard to believe (and am disappointed) that there hasn't been any traction on this. Is OAuth 2.0 not commonly used with MP by users/companies?

[smillidge]

@tdevfeeds have you considered raising a PR rather than rewriting your application to Spring. Perhaps it is less work?

[tdevfeeds]

I'm not quite following the intent of your question. Yes, I could raise a PR, spend a bunch more time trying to build Payara, and figure out how much the required JTI logic ripples in the codebase. I've already spent a couple of months just trying to figure out where in our OAuth2 architecture stack the issue was until I stumbled on that one line of code. However, this doesn't answer the discrepancy between the specs, nor have I received an answer on whether MP-JWT team actually wants JTI to be required. So, before I would even consider a PR, I would like that question answered first. If this is not the right place to ask this question, where should I ask it?