-
Notifications
You must be signed in to change notification settings - Fork 336
Description
This is a duplicate of #219, but that issue was closed and there didn't seem to be a fix for the issue.
I am using a custom JwtSecurityTokenHandler class. The ValidateToken method is overridden in the custom class. The custom JwtSecurityTokenHandler class uses a TokenValidationParameters.ClockSkew value of 5 minutes. The custom JwtSecurityTokenHandler class calls base.ValidateToken(...).
If I receive a bearer token at 9:01:00 with an expiration datetime of 9:00:00, the call to base.ValidateToken returns a ClaimsPrincipal and doesn't throw any exceptions because 9:01:00 is within the ClockSkew grace period (the ValidateToken call is successful up until 9:05:00). In that regard, the code in the custom JwtSecurityTokenHandler is working as expected. However, I'm finding that once the control flow leaves the custom JwtSecurityTokenHandler class, then something unexpected happens. The call fails with a 401 HTTP response code. OWIN logging captures the log event below:
Microsoft.Owin.Security.OAuth.OAuthBearerAuthenticationMiddleware Warning: 0 : expired bearer token received
The issue appears to be that the OAuthBearerAuthenticationHandler doesn't take into account the ClockSkew setting.
// Validate expiration time if present
DateTimeOffset currentUtc = Options.SystemClock.UtcNow;
if (ticket.Properties.ExpiresUtc.HasValue &&
ticket.Properties.ExpiresUtc.Value < currentUtc)
{
_logger.WriteWarning("expired bearer token received");
return null;
}
Is this a bug in the OAuthBearerAuthenticationHandler class or a misunderstanding on my part of how JwtSecurityTokenHandler / TokenValidationParameters.ClockSkew / OAuthBearerAuthenticationHandler are supposed to collectively work together?