Ein hybrider MVC-Client versucht, die access_token
mithilfe einer refresh_token
zu aktualisieren. Der in den Dienst eingewickelte Code ist sehr ähnlich zu https://github.com/IdentityServer/IdentityServer4.Samples/blob/293622b8438d27f4c9c2574e43fe92a22560ac6b/Clients/src/MvcHybrid/Controllers/HomeController.cs#L46, außer dass er keine Umleitung ausführt, sondern den neuen access_token
zurückgibt. Etwas völlig Unzusammenhängendes geht nach dem Serviceaufruf in der Anfragepipeline falsch (so versuchte ich, einen einfach zu reproduzierenden Fall zu erstellen).Anforderungs-Token mit einem abgelaufenen Aktualisierungstoken anfordern
[Authorize]
public async Task<IActionResult> RefreshToken()
{
ViewBag.AccessToken = await _securityTokenService.RenewToken(HttpContext);
// Something unrelated goes wrong.
throw new Exception();
// This logically never happens causing the problem.
return View("Secure");
}
Das geht gut und die refresh_token
und access_token
sind auf einen neuen Wert aktualisiert. Es tritt also logisch eine Ausnahme auf und die Ansicht wird nie zurückgegeben. Beim zweiten Aufruf dieser Methode hat der refresh_token
den gleichen Wert wie der erste refresh_token
. Daher wird eine ungültige Anforderung an den IdentityServer gesendet, da die refresh_token
abgelaufen ist (IdentityServer gibt {"error":"invalid_grant"}
zurück).
Meine Annahme ist, dass, weil die Ansicht nicht zurückgegeben wird die Token des Benutzers tatsächlich nicht aktualisiert werden, aber die refresh_token
ist als abgelaufen markiert.
Wie kann ich mit dieser Situation umgehen, die neue refresh_token
wird verwendet, um die access_token
zu aktualisieren?
Warum werfen Sie nach dem RenewToken-Anruf? –
Um eine Ausnahme irgendwo in der Pipeline zu veranschaulichen, bevor die Anfrage beendet ist. – user1336
Das Code-Snippet ist irreführend, wenn es kein richtiges Beispiel für den fehlerhaften Code ist. Stellen Sie ein [mcve] bereit, mit dem das Problem reproduziert werden kann. – Nkosi