1

I'm trying to use the jwt-1.0 feature in Open Liberty.

The JwtBuilder API is pretty nice and allows to set expiration, sign, encrypt and build a token programmatically (and everything else needed).

JwtBuilder.create().expirationTime(expTime).signWith(signAlg, privateKey).encryptWith(keyMgmtAlg, keyMgmtKey, contentEncAlg).buildJwt().compact();

But the JwtConsuer API seems pretty lame and only allows to read a token without validation at all.

JwtConsumer.create().createJwt(token);

Signature validation and decryption should be configured through the application server configuration (via "jwtConsumer" and "keystore" entries) but it's not possible programmatically. I should accommodate with this but other validations like expiration date are not possible.

Do I miss something?

Clément Honoré
  • 137
  • 1
  • 12

2 Answers2

0

You're correct in that the JwtConsumer API does not provide a programmatic way to set specific validation requirements. However the JWT will still be validated when createJwt() is called.

The JwtConsumer API's create() and create(String consumerConfigId) methods tie the JwtConsumer object to a <jwtConsumer> element in the server configuration that specifies the validation requirements. The configuration settings for that element can be viewed here: https://openliberty.io/docs/22.0.0.4/reference/config/jwtConsumer.html.

The JwtConsumer.create() method will use the default <jwtConsumer> configuration that is provided automatically by the runtime, which simply looks like this:

<jwtConsumer id="defaultJwtConsumer" />

Similarly, the JwtConsumer.create(String consumerConfigId) would use the configuration with the corresponding ID. So JwtConsumer.create("myJwtConsumer") would use the corresponding "myJwtConsumer" configuration in the server.xml. That could look something like this:

<jwtConsumer id="myJwtConsumer"
    issuer="https://example.com"
    audiences="Luke, Leia, Han"
    signatureAlgorithm="RS256"
    jwkEnabled="true"
    jwkEndpointUrl="https://..."
/>

You'd put whatever validation settings you want in that configuration. Then when you call JwtConsumer.createJwt(token), the runtime will perform several validation checks against the JWT. That includes checking the issuer, audiences, iat and exp times, the nbf claim, and of course the signature of the token.

Adam Y
  • 16
  • Thanks for your answer ! Yes, that's I wanted to say when I wrote "should be configured through the application server configuration" but I haven't found a corresponding attribute on the "jwtConsumer" entry to define validation of iat or exp. Can you point me to it ? Is it "clockSkew" ? – Clément Honoré Apr 15 '22 at 16:26
  • Ok, I've checked and setting a value for the "clockSkew" attribute activate expiration validation on the consumer. Thank you ! – Clément Honoré Apr 15 '22 at 16:32
  • The `iat` and `exp` claims should automatically be validated by the `JwtConsumer` without you having to configure anything; it will essentially validate that `iat` <= now <= `exp`. The `clockSkew` attribute is just there to account for minor differences in time between system clocks. If you're wanting a more granular check like "exp isn't 18 years in the future," then no, there isn't a way to configure that. You can, however, do additional programmatic checks on the `JwtToken` that's returned from `JwtConsumer.createJwt()`. You can call `JwtToken.getClaims()` and do whatever checks you'd like. – Adam Y Apr 15 '22 at 16:55
0

To expand on the answer, if a clockSkew is not specified, then a default value of 5 minutes is used. On the other hand, setting clockSkew="0m" will in effect disable the clock skew.

Teddy J. Torres
  • 51
  • 4