Skip to content

Fix JWT DateTimeOffset handling with DateTime.MinValue #33651

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.

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

Merged
merged 1 commit into from
Jun 23, 2021

Conversation

BrennanConroy
Copy link
Member

Fixes #33634

@BrennanConroy BrennanConroy added the area-auth Includes: Authn, Authz, OAuth, OIDC, Bearer label Jun 18, 2021
@BrennanConroy BrennanConroy requested a review from Tratcher June 18, 2021 22:57
@BrennanConroy
Copy link
Member Author

/backport to release/6.0-preview6

@github-actions
Copy link
Contributor

Started backporting to release/6.0-preview6: https://github.com/dotnet/aspnetcore/actions/runs/951304071

private static DateTime? GetSafeDateTime(DateTime dateTime)
{
// Assigning DateTime.MinValue or default(DateTime) to a DateTimeOffset when in a UTC+X timezone will throw
// Since we don't really care about DateTime.MinValue in this case let's just set the field to null
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Link to the runtime issue.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out it's by design

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Frankly, this feels like the wrong approach. That you're getting an error here means the returned DateTimes aren't DateTimeKind.Utc, which seems... not correct for their intended use. There's no reason for them to be anything other than Utc, and the fact that the "safe" method doesn't otherwise correct the issue means it's going to cause problems further down the line. If you echo/pass on the claims, is this currently causing these timestamps to change due to local/utc confusion?

The JWT claims are effectively ignorant of timezone, but are still absolute timestamps, and so can be considered UTC - a far better approach would be ensuring that the parsing method ensures that it returns the DateTime with the proper kind, and ensure that anything that could modify has the output coerced to UTC (via SpecifyKind(DateTimeKind.Utc) - which is just going to "assign" the kind, and leave the timestamp otherwise unchanged, and won't throw).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BrennanConroy BrennanConroy merged commit 7b28c2b into main Jun 23, 2021
@BrennanConroy BrennanConroy deleted the brecon/jwtdate branch June 23, 2021 22:19
@ghost ghost added this to the 6.0-preview7 milestone Jun 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-auth Includes: Authn, Authz, OAuth, OIDC, Bearer
Projects
None yet
Development

Successfully merging this pull request may close these issues.

JWTBearerHandler bug in .NET 6 preview
3 participants