Closed softwarespot closed 3 years ago
I am closing this issue, because this https://github.com/lcobucci/jwt/pull/618 pretty much states that a claims formatter should be used instead (which I did above). Ideally it should have never been a string and so I am sorry for the noise. Hopefully others can learn from this too
I have experienced issues with tokens that are created with latest https://github.com/laravel/passport. For example "exp" had the value "1644948329.528239" which is a valid float64 and json.Number. Previous this would have been "1644948329", but developers of passport decided to add additional precision.
In the end I solved this with the code at the end of this issue, but felt it would be good to report this.
What I noticed, was that when I was trying VerifyExpiresAt - https://github.com/dgrijalva/jwt-go/blob/master/map_claims.go#L23, the type was neither float64 nor json.Number, but instead string. I also created my own instance of the parser and defined "UseJSONNumber" to be true, but then my output was json.Number for those exps which were a valid float64 from before and still string for those which had the decimal precision.
After checking the claims, is that exp is stored as a string and not a number (implementation they are using . https://github.com/lcobucci/jwt, https://github.com/lcobucci/jwt/blob/2f533837091d0b76a89a059e7ed2b2732b2f459e/src/Encoding/MicrosecondBasedDateConversion.php#L29), which would make perfect sense. Also jwt.io doesn't recognise this either as it shows "Invalid date"
Before
After