SignedJWT.parse(s).getJWTClaimsSet() cannot handle null claims

Issue #261 resolved
Alastair Mailer created an issue

If any standard claims are explicitly set to null in a signed JWT, then getting the JWTClaimsSet fails (tested release 5.9)

Test:

JWSSigner jwsSigner = new RSASSASigner(KeyPairGenerator.getInstance("RSA").generateKeyPair().getPrivate());
JWSHeader header = new JWSHeader.Builder(JWSAlgorithm.RS256).build();
JWSObject jwt = new JWSObject(header, new Payload("{\"sub\": null}"));
jwt.sign(jwsSigner);
String jwtString = jwt.serialize();
SignedJWT.parse(jwtString).getJWTClaimsSet();

Exception:

java.text.ParseException: JSON object member with key "sub" has null value

at com.nimbusds.jose.util.JSONObjectUtils.getGeneric(JSONObjectUtils.java:126)
at com.nimbusds.jose.util.JSONObjectUtils.getString(JSONObjectUtils.java:243)
at com.nimbusds.jwt.JWTClaimsSet.parse(JWTClaimsSet.java:882)
at com.nimbusds.jwt.SignedJWT.getJWTClaimsSet(SignedJWT.java:92)
at com.avaloq.aws.server.security.ExternallyIssuedTokensTest.test(ExternallyIssuedTokensTest.java:65)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.mockito.internal.runners.DefaultInternalRunner$1.run(DefaultInternalRunner.java:78)
at org.mockito.internal.runners.DefaultInternalRunner.run(DefaultInternalRunner.java:84)
at org.mockito.internal.runners.StrictRunner.run(StrictRunner.java:39)
at org.mockito.junit.MockitoJUnitRunner.run(MockitoJUnitRunner.java:161)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)

Comments (4)

  1. Vladimir Dzhuvinov

    As work around use

    signedJWT.getPayload().toJSONObject()
    

    which will give you the underlying JSON object.

  2. Alastair Mailer Account Deactivated reporter

    Hello, thanks for the workaround; unfortunately that is quite painful as we have had to isolate the net.minidev dependencies due to a clash on transitive dependencies (asm major version mismatch) - therefore cannot easily directly access the JSONObject class.

  3. Log in to comment