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
- Related to quarkusio/quarkus#1710 add request scoping to endpoints and add native image test, docs — committed to quarkusio/quarkus-quickstarts by starksm64 5 years ago
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 aboutJsonString, 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
@Claimwith a proxyble class is fine. The issue is with non-proxyble classes, where of course, the injected value is the one retrieve when the@ApplicationScopedbean was created and stays there forever.Additional references from the MP JWT Spec: https://github.com/eclipse/microprofile-jwt-auth/pull/180