Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

JWT claim in the form of DateTime get extra double-quote when converted to claims #1261

Closed
oliviervaillancourt opened this issue Oct 1, 2019 · 1 comment
Closed

JWT claim in the form of DateTime get extra double-quote when converted to claims #1261

oliviervaillancourt opened this issue Oct 1, 2019 · 1 comment
Assignees
@GeoK
Labels
Bug Product is not functioning as expected Customer reported Indicates issue was opened by customer P1 More important, prioritize highly
Milestone
5.6.0

Comments

@oliviervaillancourt
Copy link

Hi,

After an upgrade from 4.x to 5.5 of System.IdentityModel.Tokens.Jwt, we are noticing that if we read a Jwt that has a claim as a DateTime, then the value of Claim object is surrounded with double-quote.

Repro:
run this code:

var backendToken = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjbGFpbV9hc19kYXRldGltZSI6IjIwMTktMTEtMTVUMTQ6MzE6MjEuNjEwMTMyNloifQ.yYcHSl-rNT2nHe8Nb0aWe6Qu3E0ZOn2_OUidpxuw0wk";

            var handler = new JwtSecurityTokenHandler();

            var token = handler.ReadToken(backendToken) as JwtSecurityToken;
            var dateClaim = token.Claims.First();

            var claimValue = dateClaim.Value;
            Console.WriteLine(claimValue);

Notice that the value of claimValue is "2019-11-15T14:31:21.6101326Z" instead of 2019-11-15T14:31:21.6101326Z (extra double-quote).

From looking into the code a little it seems that this related to the use of JsonConvert.DeserializeObject without specifying a DateFormatHandling property.

Thanks
@brentschmaltz brentschmaltz added P1 More important, prioritize highly Customer reported Indicates issue was opened by customer Bug Product is not functioning as expected labels Oct 4, 2019
@brentschmaltz brentschmaltz modified the milestones: 5.x Release, 5.6.0 Oct 8, 2019
@mafurman mafurman assigned GeoK and unassigned GeoK and mafurman Oct 14, 2019
@GeoK GeoK mentioned this issue Oct 17, 2019
Closed
GeoK added a commit that referenced this issue Oct 17, 2019
@GeoK
Fix DateTime claims processing
131cfe2 
Currently, claims created from a deserialized JSON string might have
'System.DateTime' or ClaimValueTypes.String type, depending on the
format of a datetime json string, the way how JSON string was
deserialized, and json handler being used.

This PR changes fixes this inconsistency, so claims that hold DateTime
values always have ClaimValueTypes.String as a type.

Also, by default, Newtonsoft.JSON serializer encloses some DateTime
strings with quotes which results in ""dateTimeValue"" (see #1261).
This behavior is changed, so that resulting string doesn't contain the
double quotes.

DateTime claim value (string) is now created as an UTC string
represented in ISO 8061 date-time format, if a DateTime claim is added
directly (via 'JwtPayload.Add()').

Replacing JObject.Parse with JObject.Load isn't introducing any performance
overhead.
GeoK added a commit that referenced this issue Oct 17, 2019
@GeoK
Fix DateTime claims processing
e4d400e 
Currently, claims created from a deserialized JSON string might have
'System.DateTime' (invalid claim type) or ClaimValueTypes.String type,
depending on the format of a datetime json string, the way how JSON
string was deserialized, and json handler being used.

This PR changes fixes this inconsistency, so claims that hold DateTime
values in ISO8061 datetime format will always have
ClaimValueTypes.DateTime as a claim value type. DateTime strings
represented in datetime formats other than ISO8061 will have
ClaimValueTypes.String as a claim value type.

Also, by default, Newtonsoft.JSON serializer encloses some DateTime
strings with quotes which results in ""dateTimeValue"" (see #1261).
This behavior is changed, so that resulting string doesn't contain the
double quotes.

DateTime claim value (string) is now created as an UTC string
represented in ISO 8061 date-time format, if a DateTime claim is added
directly (via 'JwtPayload.Add()').
@GeoK GeoK mentioned this issue Oct 17, 2019
Merged
GeoK added a commit that referenced this issue Oct 18, 2019
@GeoK
Fix DateTime claims processing
e72392b 
Currently, claims created from a deserialized JSON string might have
'System.DateTime' (invalid claim type) or ClaimValueTypes.String type,
depending on the format of a datetime json string, the way how JSON
string was deserialized, and json handler being used.

This PR changes fixes this inconsistency, so claims that hold DateTime
values in ISO8061 datetime format will always have
ClaimValueTypes.DateTime as a claim value type. DateTime strings
represented in datetime formats other than ISO8061 will have
ClaimValueTypes.String as a claim value type.

Also, by default, Newtonsoft.JSON serializer encloses some DateTime
strings with quotes which results in ""dateTimeValue"" (see #1261).
This behavior is changed, so that resulting string doesn't contain the
double quotes.

DateTime claim value (string) is now created as an UTC string
represented in ISO 8061 date-time format, if a DateTime claim is added
directly (via 'JwtPayload.Add()').
GeoK added a commit that referenced this issue Oct 18, 2019
@GeoK
Fix DateTime claims processing (#1281)
501095c 
Currently, claims created from a deserialized JSON string might have
'System.DateTime' (invalid claim type) or ClaimValueTypes.String type,
depending on the format of a datetime json string, the way how JSON
string was deserialized, and json handler being used.

This PR changes fixes this inconsistency, so claims that hold DateTime
values in ISO8061 datetime format will always have
ClaimValueTypes.DateTime as a claim value type. DateTime strings
represented in datetime formats other than ISO8061 will have
ClaimValueTypes.String as a claim value type.

Also, by default, Newtonsoft.JSON serializer encloses some DateTime
strings with quotes which results in ""dateTimeValue"" (see #1261).
This behavior is changed, so that resulting string doesn't contain the
double quotes.

DateTime claim value (string) is now created as an UTC string
represented in ISO 8061 date-time format, if a DateTime claim is added
directly (via 'JwtPayload.Add()').
GeoK added a commit that referenced this issue Oct 18, 2019
@GeoK
Fix DateTime claims processing (#1281)
d633b4f 
Currently, claims created from a deserialized JSON string might have
'System.DateTime' (invalid claim type) or ClaimValueTypes.String type,
depending on the format of a datetime json string, the way how JSON
string was deserialized, and json handler being used.

This PR changes fixes this inconsistency, so claims that hold DateTime
values in ISO8061 datetime format will always have
ClaimValueTypes.DateTime as a claim value type. DateTime strings
represented in datetime formats other than ISO8061 will have
ClaimValueTypes.String as a claim value type.

Also, by default, Newtonsoft.JSON serializer encloses some DateTime
strings with quotes which results in ""dateTimeValue"" (see #1261).
This behavior is changed, so that resulting string doesn't contain the
double quotes.

DateTime claim value (string) is now created as an UTC string
represented in ISO 8061 date-time format, if a DateTime claim is added
directly (via 'JwtPayload.Add()').
@GeoK
Copy link
Member

GeoK commented Oct 18, 2019

Thank you for reporting this issue @oliviervaillancourt.
The fix will be released in v5.6.0.

@GeoK GeoK closed this as completed Oct 18, 2019
@brentschmaltz brentschmaltz mentioned this issue Oct 18, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@GeoK GeoK

Labels
Bug Product is not functioning as expected Customer reported Indicates issue was opened by customer P1 More important, prioritize highly
Projects
None yet
Milestone
5.6.0
Development

No branches or pull requests
4 participants
@GeoK @brentschmaltz @oliviervaillancourt @mafurman