AuthenticationResponse.ExpiresAt timezone parsing error?

[OlegBoulanov]

Current behavior

Works fine in EST TZ (+5:00)

To reproduce the error, set computer UTC timezone (currently +1:00), try to

AuthenticationResponse = await authenticationClient.AuthenticateAsync(new AuthenticateOptions { Username = UserName, Password = Password } ...

18:41:39.745 User XXX authenticated: MFA_REQUIRED: AuthenticationResponse.ExpiresAt == 9/15/2020 17:46:38 +01:00

55 minutes ago?

Expected behavior

18:41:39.745 User XXX authenticated: MFA_REQUIRED: AuthenticationResponse.ExpiresAt == 9/15/2020 18:46:38 +01:00

in 5 minutes

Minimal reproduction of the problem with instructions

Check the time here: https://github.com/OlegBoulanov/okta-auth-dotnet/blob/61487890f1afbb8fd3e10f32cc7a3c7e4405cd88/Okta.Auth.Sdk.UnitTests/AuthenticationClientShould.cs#L184

	Name	Value	Type
	rawResponse	"\r\n {\r\n "expiresAt": "2015-11-03T10:15:57.000Z",...	string

	Name	Value	Type
▶	ExpiresAt	{11/3/2015 10:15:57 -05:00}	System.DateTimeOffset?

Environment

• OS: Windows 10

• .Net Framework: 4.61, 4.72

Related issue: okta/okta-sdk-dotnet#347 ??

[bryanapellanes-okta]

@OlegBoulanov ,
Thank you for submitting this issue and I'm sorry for the inconvenience. We will review the reproduction steps and provide additional information here when we have more to share. Stay tuned!

[OlegBoulanov]

After this line:

okta-auth-dotnet/Okta.Auth.Sdk.UnitTests/AuthenticationClientShould.cs

Line 214 in bb14b9d

authResponse.ExpiresAt.Value.Date.Should().Be(new DateTime(2015, 11, 3));

add:
authResponse.ExpiresAt.Value.Should().Be(DateTimeOffset.Parse("2015-11-03T10:15:57.000Z"));

and see the test fail:
Expected authResponse.ExpiresAt.Value to be <2015-11-03 10:15:57>, but it was <2015-11-03 10:15:57 -5h>

The expected value taken from here:

okta-auth-dotnet/Okta.Auth.Sdk.UnitTests/AuthenticationClientShould.cs

Line 180 in bb14b9d

""expiresAt"": ""2015-11-03T10:15:57.000Z"",

[bryanapellanes-okta]

@OlegBoulanov,
I'm able to reproduce the behavior in the tests that you describe, however, I'm unclear how this issue manifests in a production scenario. The test code uses a mock response so I want to be careful not to conflate mock test results with a potential production issue. Are the results you describe happening from calls to the production endpoints?

[bryanapellanes-okta]

@OlegBoulanov,
When I make calls to the production endpoints, I currently receive a response which expires 8 hours into the future. Let me know if your results are not as expected and I will investigate further.

[OlegBoulanov]

@bryanapellanes-okta
As far as I understand, the intention was for password authentication response to expire in 5 minutes.
Misinterpreting expireAt results in different expiration times, depending on user's time zone! That's how we discovered the issue - everything worked (with a weird expiration time) in the US (EST) negative shift TZ, but expired instantly as soon as we tried it in London, currently +1:00 due to daylight saving time.
Of course, one can just ignore the returned value (as I do now as a workaround), but. Bugs. Have to be fixed.