Identity Server 3 odświeżania tokenu wygasa przed jej okresu ważności określonym w konfiguracji klienta

Question

używam przepływ kod autoryzacji dla jednego z moich Identity Server 3 klientów i jest skonfigurowana w następujący sposób:

ClientId = "tripgalleryauthcode", 
ClientName = "Trip Gallery", 
Flow = Flows.AuthorizationCode, 
AllowAccessToAllScopes = true, 
RequireConsent = false, 

// redirect = URI of our callback controller in the IOS application 
RedirectUris = new List<string> 
{ 
    "somecallbackuri" 
},   

ClientSecrets = new List<Secret>() 
{ 
    "somesecret" 
}, 

// refresh token options 
AccessTokenType = AccessTokenType.Jwt, 
AccessTokenLifetime = 120, 
RefreshTokenUsage = TokenUsage.OneTimeOnly, 
RefreshTokenExpiration = TokenExpiration.Absolute, 
AbsoluteRefreshTokenLifetime = 360, 

Jak widać Jest skonfigurowany tak, aby wygasał token dostępu w ciągu 2 minut, a token odświeżania w ciągu 6 minut. Zrobiłem to, ponieważ chciałem spróbować rozwiązać problem w mniejszym przedziale czasowym niż ten, którego używam w produkcji: 15 dni na token odświeżania, 1 godzinę na token dostępu. Zauważyliśmy, że z jakiegoś powodu odświeżony dzisiaj token nie działa jutro. Dlatego zdecydowałem się zmniejszyć czasy i to, co się stało:

1. At 1:05 PM Zrobiłem odświeżania tokenu żądania i otrzymał nowe refres i tokeny dostępu
2. Teraz spodziewam moje odświeżania tokena wygasa o 01:11
3. O 13:10 Wykonuję połączenie do punktu końcowego tokenu za pomocą typu dotacji refresh_token, próbując uzyskać nowy dostęp i odświeżenie tokenów. Co się dzieje, to otrzymuję błąd HTTP 400 mówiący, że jest to invalid_grant.

Zauważyłem nawet trochę więcej. Co się stanie, 2 minuty po wygaśnięciu tokena dostępu otrzymam błąd 400. Mówi, że token odświeżania jest nieprawidłowy.

To jest dziennik z serwera tożsamości.

w3wp.exe Information: 0 : 2016-11-23 10:56:15.802 +00:00 [Information] Start token request 
w3wp.exe Information: 0 : 2016-11-23 10:56:15.802 +00:00 [Information] Client secret id found: "tripgalleryauthcode" 
w3wp.exe Information: 0 : 2016-11-23 10:56:15.802 +00:00 [Information] Client validation success 
w3wp.exe Information: 0 : 2016-11-23 10:56:15.802 +00:00 [Information] Start token request validation 
w3wp.exe Information: 0 : 2016-11-23 10:56:15.802 +00:00 [Information] Start validation of refresh token request 
w3wp.exe Warning: 0 : 2016-11-23 10:56:15.802 +00:00 [Warning] "Refresh token has expired" 
"{ 
    \"ClientId\": \"tripgalleryauthcode\", 
    \"ClientName\": \"Trip Gallery\", 
    \"GrantType\": \"refresh_token\", 
    \"RefreshToken\": \"d12f50289e5cded13082de989a64ac01\", 
    \"Raw\": { 
    \"grant_type\": \"refresh_token\", 
    \"refresh_token\": \"d12f50289e5cded13082de989a64ac01\" 
    } 
}" 
w3wp.exe Information: 0 : 2016-11-23 10:56:15.818 +00:00 [Information] End token request 
w3wp.exe Information: 0 : 2016-11-23 10:56:15.818 +00:00 [Information] Returning error: invalid_grant 

Naprawdę chciałbym wiedzieć, co powoduje, że to zachowanie i to, co powoduje wygaśnięcie mojego tokena wygaśnięcia przed upływem terminu.

Answer 1

Powodem, dla którego tak się dzieje, jest funkcja wbudowanego zegara w JWT, która chroni Cię przed synchronizacją zegarów. Bez tego możesz napotkać problemy, w których tokeny nie są jeszcze ważne.

Wartość domyślna to 5 minut - dotyczy to access_token, a także refresh_token.

można zmienić tę wartość z JwtBearerOptions.TokenValidationParameters.ClockSkew w IdentityServer4.AccessTokenValidation.CombinedAuthenticationOptions

Takie zachowanie jest również określona w official JWT Draft:

Realizatorzy może przewidywać niewielkim swobodę, zazwyczaj nie więcej niż kilka minut, aby uwzględnić skos zegara. Jego wartość MUSI być numerem zawierającym wartość IntDate. To roszczenie jest OPCJONALNE.