[Bug] Evaluate usage of DateTime.TryParse for performance

[eerhardt]

Which version of Microsoft.IdentityModel are you using?
latest version.

Where is the issue?

• M.IM.JsonWebTokens
• M.IM.KeyVaultExtensions
• M.IM.Logging
• M.IM.ManagedKeyVaultSecurityKey
• M.IM.Protocols
• M.IM.Protocols.OpenIdConnect
• M.IM.Protocols.SignedHttpRequest
• M.IM.Protocols.WsFederation
• M.IM.TestExtensions
• M.IM.Tokens
• M.IM.Tokens.Saml
• M.IM.Validators
• M.IM.Xml
• S.IM.Tokens.Jwt
• Other (please describe)

Repro

Looking at a CPU profile of validating JWT tokens, between 5-8% of the time is spent in 2 calls to DateTime.TryParse:

azure-activedirectory-identitymodel-extensions-for-dotnet/src/Microsoft.IdentityModel.Tokens/Json/JsonSerializerPrimitives.cs

Line 713 in 753959a

if (DateTime.TryParse(originalString, out DateTime dateTimeValue))

azure-activedirectory-identitymodel-extensions-for-dotnet/src/Microsoft.IdentityModel.JsonWebTokens/JwtTokenUtilities.cs

Lines 602 to 604 in 753959a

	internal static string GetStringClaimValueType(string str)
	{
	if (DateTime.TryParse(str, out DateTime dateTimeValue))

For every string claim in the JWT, we are calling DateTime.TryParse on each value, whether it is expected to be a DateTime or not. This is expensive. We should consider if can eliminate these calls, or only call them if necessary.

[brentschmaltz]

@eerhardt Excellent find, this was added for backcompat.
We should state what claims we will consider as a possible datetime, ignore the rest.

I think we need to wrap this in a AppContext switch as we could break users.
We are investigating an API that will give users the ability to step in front of property claim.
When that API is ready, users will be able to handle specific claims.