JWT caching

[mkleczek]

In our set-up we use asymmetric encryption to authenticate JWTs. As crypto operations are quite resource intensive we would like to cache results of JWT validation.

From my limited understanding of Haskell code JWTs are validated and parsed upon every request.

Do you think it would be a good idea to provide a time limited cache of JWT validation/parsing results?

[steve-chavez]

Yes, JWTs are validated on each request.

Do you know a good implementation of JWT caching? I'm not sure if doing this would be safe.

Some references:

• Security Vulnerability - Server Cache allows bypass of JWT Validation zmartzone/lua-resty-openidc#399
• https://stackoverflow.com/questions/59877621/is-it-okay-to-cache-verified-jwt-token-to-prevent-repeated-verification-process

[mkleczek]

I think caching validation/parsing result is secure as long as cache entry is not available longer than the token validity. I guess https://hackage.haskell.org/package/cache might support what is needed.

I will try to provide a patch but it is going to be my first real Haskell adventure :)

[taimoorzaeem]

@steve-chavez, for this I am thinking of adding two config options: jwt-exp-claim and jwt-caching. As specified in RFC 7519 the exp should be a NumericDate value.

I guess we need this other config jwt-caching which would be a boolean specifying if caching is used. What do you think? Also what do you think would be an appropriate format for NumericDate value?

[steve-chavez]

I am thinking of adding two config options: jwt-exp-claim and jwt-caching

@taimoorzaeem Hm, I don't think we need a jwt-exp-claim. The exp should already be specified by the JWT provider, we only need to consume it. Also exp is a registered claim so we shouldn't need to specify a different key for obtaining it (like we do with the role on jwt-role-claim-key).

As for a boolean jwt-caching, yes, we would need it.

[steve-chavez]

@taimoorzaeem Thinking more about this, we would need a way to test that the jwt decoding is fast the second time.

Looks like #2771 might help. Check my comment, for starters it seems possible to add Server-Timing for only the jwt decoding.

[taimoorzaeem]

From #2771 (comment) here:

To avoid doing this work for all the requests:

• We can add Server-Timing whenever the Prefer: server-timing=include header is specified.
• Or enable it whenever db-plan-enabled is turned on.

@steve-chavez What do you think, should I add Prefer: server-timing=include or just go with db-plan-enabled for now?

[steve-chavez]

@taimoorzaeem db-plan-enabled would be good, seems simpler.

[taimoorzaeem]

@steve-chavez The exact matching won't work here, because the duration changes from run to run. How should I compare them?

Failures:

  test/spec/Feature/Auth/JwtCaching.hs:19:7: 
  1) Feature.Auth.JwtCaching.jwtCaching initial jwt validation
       missing header:
         Server-Timing: jwt;dur=
       the actual headers were:
         Content-Range: 0-0/*
         Server-Timing: jwt;dur=223.9
         Content-Type: application/json; charset=utf-8

  test/spec/Feature/Auth/JwtCaching.hs:27:7: 
  2) Feature.Auth.JwtCaching.jwtCaching jwt validation time reduces this time
       missing header:
         Server-Timing: jwt;dur=
       the actual headers were:
         Content-Range: 0-0/*
         Server-Timing: jwt;dur=136.4
         Content-Type: application/json; charset=utf-8

Also, the way I have currently implemented this is that I have made the JWT Cache a part of AppState. So, does running two spec-tests one after the other changes AppState or is it "rollbacked" after running a single test case?

[steve-chavez]

How should I compare them?

@taimoorzaeem I think we can assert that the 2nd duration will always be less than the 1st. Some light parsing (like using Text.split, there's an example in Mediatype.hs IIRC) could be done to extract the value from the header and compare them.

[steve-chavez]

Re AppState, seeing the feature code would give me a better idea (maybe you can do a draft PR). But if it's too difficult as a spec test, you could always make it an io test.