quarkus: smallrye-jwt returns stale claim data from previous JWT

It seems that the quarkus smallrye-jwt integration holds on to values from previous JWT invocations and returns stale claim values instead of the ones from the current JWT.

E.g. accessing currentUsername always returns the value from the first JWT that was used to call the /data/user endpoint.

import org.eclipse.microprofile.jwt.Claim;
import org.eclipse.microprofile.jwt.Claims;

import javax.annotation.security.RolesAllowed;
import javax.inject.Inject;
import javax.json.Json;
import javax.json.JsonString;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import java.util.Optional;

@Path("/data")
public class DataResource {

    private static final JsonString ANOYNMOUS = Json.createValue("anonymous");
   
    @Inject
    @Claim(standard = Claims.preferred_username)
    Optional<JsonString> currentUsername;

    @GET
    @Path("/user")
    @Produces(MediaType.TEXT_PLAIN)
    @RolesAllowed({"user"})
    public String userData() {
        return "data for user " + currentUsername.orElse(ANOYNMOUS);
    }
}

See discussion on twitter: https://twitter.com/thomasdarimont/status/1110569492520808450 The following example helps to reproduce the issue: https://github.com/thomasdarimont/quarkus-keycloak-demo

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 26 (25 by maintainers)

Commits related to this issue

Most upvoted comments

My statement was indeed about JWT (>= JsonWebToken), not about some of its individual claims, especially those with the non-proxiable types. This particular issue is about JsonString, I’m hoping we can close this really soon now 😃, but need some help from @mkouba to clarify a few bits 😃

I think it would make sense to add some more details to the documentation (guides). I found two slightly contradictory statements there (see Zulip), which may also apply to others. The explanations here make perfectly sense and explain the limitations very well.

Depends, using @Claim with a proxyble class is fine. The issue is with non-proxyble classes, where of course, the injected value is the one retrieve when the @ApplicationScoped bean was created and stays there forever.

Additional references from the MP JWT Spec: https://github.com/eclipse/microprofile-jwt-auth/pull/180