RE: JWT's and validation

[sbditto85]

What are your thoughts on adding a unsafeJWTClaims like function where we can get the claims in the JWT without claims validation (but still validate the signature).

My motivating case is we have multiple services running that pass a JWT for validation if the token just happens to expire in the middle of a transaction I'd like to refresh the token rather then abort the transaction, in order to refresh the token I would need to access the claims to use the identity to verify the token can still be refreshed.

I understand that the idea is to never use the JWT without it being valid so having a function prefaced with unsafe hopefully makes it clear that using it is more of an edge case then the norm.

Thoughts?

[frasertweedale]

Hi. You can set an allowed skew in the JWT validation settings: https://hackage.haskell.org/package/jose-0.7.0.0/docs/Crypto-JWT.html#t:HasAllowedSkew

If you really want to get the claims out of an expired token, you can set a high allowed skew and use the standard validation function.

[frasertweedale]

Closing (there is a workaround).

[sbditto85]

hummm, i'm rather disappointed in this response. It seems like a big hack rather then a designed API. I personally don't see whats wrong with exposing an "unsafe" function to bypass all the validation code when you don't want to run the validation code.

[frasertweedale]

@sbditto85, the "unsafe" variant you describe, apart from violating https://tools.ietf.org/html/rfc7519#section-4.1.4, violates the library's philosophy of ensuring (to the extent possible) correct and safe behaviour. Your use case is valid, but given the existence of workarounds, it does not overrule those concerns.

Happy to discuss further the specifics of your use case / architecture, to see if we can identify a mutually satisfactory solution.

[sbditto85]

the idea of having an "unsafe" function is to break the safe specification with the understanding that if you do so its at your own risk and "there be dragons" if you use it incorrectly.

It seems a somewhat common idiom to force correct uses through the types and functions, but where applicable provide an unsafe "escape hatch" if needed for the random one off cases . Just cranking up the tolerances of the EXP field or other date time fields seems like were telling ourselves its ok because were using a safe API, but really the token is still just as bad. I know its bad and just want the data so i can do some logic on the data when I'm in a state of knowing the token is bad.

In a way its worse to use the work around because someone later might come by and not realize its using very loose tolerances and assume that its valid or refactor code incorrectly. Making it explicit that is not the case may help make the code more obvious.