Add verification of arbitrary claims

[toonetown]

See #26 and #23 for details of this feature.

[fermaem]

Sorry for asking if that's obvious, but in which validation context should one use this?

[toonetown]

I use it, for example, to check the iat claim.

[fermaem]

Hmmm. I must be missing something.

In order to check the iat claim, I'd may check its value isn't greater than now (+/- leeway). Optionally I may enforce it's less than exp (+/- leeway), in order to assess the jwt integrity.

However, I'm not sure how checking iat equals now could be any reliable. A jwt is supposed to last for some time, and be reused across many calls, so as soon as the leeway is exceeded, this validation will be failing (even if the jwt is still valid (eg. not expired yet)).

It's far possible I have misunderstood your point. Would that be the case, i apologize in advance. However, I'd be a taker for any explanation you may share to help me get a better grasp at this subject.

[toonetown]

@fermaem
A jwt is supposed to last for some time, and be reused across many calls

This I believe is where the difference lies, I believe. There is actually no requirement that jwt tokens are reused - and we use single-use tokens in my application. We use iat (within the leeway) as a "quick" check for validity - and we also use jti to ensure that each token is only used once.

It would be the exact same thing as setting (on the client) nbf=now() and exp=now()+1 and putting that in the token. But it is smaller and more concise to use iat.

This check (server-side) might have been able to be replaced with _M.chain(_M.is_not_before(), _M.is_not_expired()) except for something is expired when it equals the date...meaning that the chain function will fail every time (because nothing is >=now() and <now()).

If it is not desired, I can remove this call...but it seems that it actually does fit a use case (mine 😄). Even if someone wanted to use it in validating a my_custom_claim claim, or something. There is just a "hole" (==) in between is_not_before (>=) and is_not_expired (<) which I think could be filled.

[toonetown]

Also - thank you very much for the review - and please keep bringing up any issues that may be in the code (or even in my approach altogether). This is my first stab at it, and I think that needing to explain and defend what I chose to do and am doing is a valuable part of this review process. Perhaps there should be better documentation around this function or perhaps it should be removed entirely (if it encourages bad practices).

[fermaem]

and we use single-use tokens in my application.

Oh! That now makes a lot more sense.

I haven't initially thought about this angle. Indeed, in order to enforce a single usage of each token within a limited timeframe, I would rather have relied on jti+nbf+exp (but that's because I kind of prefer explicitness 😉).

If it is not desired, I can remove this call...but it seems that it actually does fit a use case

Honestly, I don't know. This is actually the first time I see (or hear of) using the iat claim to fit that purpose. @SkyLothar Thoughts?

Perhaps there should be better documentation around this function

Would @SkyLothar like the validator, I think we should however add a tiny paragraph explaining in which context this validator should be used (and when it shouldn't).

[SkyLothar]

I agree with @fermaem .
It's more explicit to use jti+nbf+exp to achieve your goal.

[SkyLothar]

But it's really a interesting.
Add some explanation for your use case, you can leave the validator here if you want, it's your call.

[toonetown]

I think I would like to leave the validator...the main purpose of the validator library is to have some simple "common" checks...and I think that checking that a time is equal to now is a fairly decent check to have, regardless. I'll update the README with some explanation for the use case.

[SkyLothar]

That's a lot of code!
Thank you 👍