-
Notifications
You must be signed in to change notification settings - Fork 279
Builder serializes integers as floats, which subsequently fail to Decode. #142
Comments
Yep, that looks like a bug. I'll have to think about how to best fix this. |
Seems like this should fix it:
Example: https://play.golang.org/p/2irRfWlxgN
So that should preserve ints as ints, and floats as floats. I'll make a PR shortly. |
We normalize claims for tokens given to us in the builder by marshaling and then unmarshaling as a JSON object. However, because JSON officially only supports floating-point numbers, this loses precision for integers embedded in structs. We switch to using json.Decoder (with UseNumber option) to decode numbers into json.Number, which preserves the precise value for both integers and floats.
We normalize claims for tokens given to us in the builder by marshaling and then unmarshaling as a JSON object. However, because JSON officially only supports floating-point numbers, this loses precision for integers embedded in structs. We switch to using json.Decoder (with UseNumber option) to decode numbers into json.Number, which preserves the precise value for both integers and floats.
Preserve integers when normalizing JWT claims (fixes #142)
Thanks a lot for fixing it! I got caught with the same problem. I spent like 3 days to figure out why AWS AssumeRoleWithWebIdentity did not understand my ID token's Any reason why go-jose.v2 serializes int as float? When I swapped to Furthermore, not sure why, but when you do Otherwise, I think we can close this issue. (: |
You can ignore me on that:
AWS STS server seems to be just broken if it does not accept fractional part with exponential E notation in JSON as number.. |
Sorry, I haven't tagged a release with the fix yet. That's why |
So any unmarshaller (jose and encode/json) parses normally any number to
It is kind of expected, so old normalize was simply losing concrete type info. Fixed normalize helped with my case.
This is what I called |
Cool. Tagged release v2.1.1 with the normalize bug fix. |
Assuming I'm doing this all using the blessed path. I've included a snippet at the bottom to demonstrate.
Relevant output produced:
If you base64 decode the 2nd component of the compact JWT you'll see
"number": 1e+06
.I suspect the culprit is here: https://github.com/square/go-jose/blob/v2/jwt/builder.go#L132 - the Marshal/Unmarshal loses the type information that would otherwise cause go's marshaler to encode
Number
as an integer.The text was updated successfully, but these errors were encountered: