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.

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

Test-PodeJwt exp and nbf validation incorrect #1083

Closed
avin3sh opened this issue Mar 6, 2023 · 0 comments · Fixed by #1084
Closed

Test-PodeJwt exp and nbf validation incorrect #1083

avin3sh opened this issue Mar 6, 2023 · 0 comments · Fixed by #1084
Labels
Milestone

Comments

@avin3sh
Copy link
Contributor

avin3sh commented Mar 6, 2023

Describe the Bug

Test-PodeJwt, responsible for validating JWT payload when using JWT auth scheme will return The JWT has expired in certain scenarios based on the machine's local timezone even though the JWT expiry is in future.

Steps To Reproduce

This can be reproduced by enabling JWT authentication, and changing the machine timezone ahead of UTC.

Expected Behavior

If JWT exp is in future, Pode should not return The JWT has expired

Platform

  • OS: Windows
  • Browser: Chrome, Firefox
  • Versions:
    • Pode: Pode v2.8.0
    • PowerShell: PS5.1, PS 7.2.4

Additional Context

As per the definition of NumericDate in rfc7519 exp and nbf should represent "...number of seconds from 1970-01-01T00:00:00Z UTC...".

However, given the following initialization in Cryptography.ps1

$now = [datetime]::Now
$unixStart = [datetime]::new(1970, 1, 1)

The Kind for these objects will be Local and Unspecified respectively.

As per Remarks in DateTime.Equality documentation,

The Equality operator determines whether two DateTime values are equal by comparing their number of ticks. Before comparing DateTime objects, make sure that the objects represent times in the same time zone. You can do this by comparing the values of their Kind property.

The value for Ticks property would be different when DateTimeKind is specified, vs. when it is not

PS C:> ([datetime]::new(1970, 1, 1)).Ticks
621355968000000000
PS C:> ([datetime]::new(1970, 1, 1, 0, 0, [DateTimeKind]::Utc)).Ticks
621355968010000000

This makes the existing implementation of JWT validation invalid. This could be fixed by initializing $now as UtcNow and using the overload that allows specifying DateTimeKind for $unixStart. I will share a PR for this shortly in case it is helpful.

@Badgerati Badgerati added this to the 2.8.1 milestone Apr 24, 2023
@Badgerati Badgerati modified the milestones: 2.8.1, 2.9.0 Jul 7, 2023
@Badgerati Badgerati mentioned this issue Oct 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants