Dies ist eher eine Design / Approach-Frage ...
Ich denke, ich vermisse etwas hier. Wir erstellen eine Asp.Net MVC 5-Webanwendung und sichern sie mit Azure AD unter Verwendung des folgenden Szenarios:
Der Token / Cookie ist ein absoluter Ablauf und läuft nach einer Stunde ab. Was macht das für die Benutzererfahrung? Jede Stunde müssen sie sich wieder einloggen, egal was? Wenn der Benutzer in unserem Test abläuft, wird der Browser zurück zu AD umgeleitet und der Benutzer aufgefordert, Anmeldeinformationen einzugeben. Dies bricht natürlich alle AJAX-Aufrufe, bei denen Teilansichten geladen werden, und keine unserer DevExpress-Steuerelemente ist daher stabil.
Basierend auf der Antwort auf diesen SO-Post: MVC AD Azure Aktualisieren Token über ADAL JavaScript Ajax und KnockoutJs
... was ich sehe, wird erwartet? Es scheint mir keine brauchbare Lösung für eine Cloud-basierte Branchenanwendung zu sein, in der Benutzer den ganzen Tag eingeloggt sind und arbeiten.
Vermisse ich etwas? Oder ist das nicht gerade ein ideales Szenario für Business-Apps?
Wir waren mit ähnlichen Problemen konfrontiert und hatten die gleichen Gedanken dazu, wie Sie Azure AD mit ASP.NET MVC in Web-Apps mit einem so geringen Sitzungszeitlimit (60 Minuten) verwenden können.
Die Lösung, die wir gefunden haben und die zu funktionieren scheint (wenn auch mit begrenzten Tests), ist ein iFrame auf der Seite, den wir alle 5 Minuten aktualisieren.
%Vor%Die Seite "CheckSessionTimeout" ist grundsätzlich leer.
In einer Javascript-Datei, auf die von der ganzen App verwiesen wird, haben wir:
%Vor%(NB: Moment ist eine JS Datum / Zeit-Bibliothek, die wir verwenden). Auf dem Home-Controller haben wir:
%Vor%Ich bin mir nicht sicher, ob das der beste Weg ist. Mit Azure AD- und ASP.NET MVC-Apps (die keine SPAs sind, keine Web-API verwenden, sondern Ajax-Aufrufe verwenden), können wir die Probleme, die mit den Azure AD- und ASP.NET-MVC-Apps einhergehen, relativ gut beheben Von all dem geht nichts mit lokalen Apps, die Kerberos-Authentifizierung machen (und die Erwartungen unserer Benutzer, dass das Sitzungs-Timeout nichts ist, was sie sehen oder sich Sorgen machen wollen).
Es gibt zwei Möglichkeiten, damit umzugehen (zumindest so machen wir es in unserer Anwendung; es wäre interessant zu sehen, was AD-Gurus dazu sagen, damit wir es auch reparieren können, wenn es nicht das ist richtiger Weg, Dinge zu tun):
Allgemeiner Ansatz - Verwenden Sie den Aktualisierungstoken
Wenn Sie ein Zugriffstoken von AD erhalten, erhalten Sie heute drei Dinge zurück - Zugriffstoken, Zugriffstokenablauf und ein Aktualisierungstoken. Was Sie tun, ist alle drei in Ihrer Anwendung zwischenzuspeichern. Bis das Zugriffs-Token abgelaufen ist, können Sie einfach dieses Zugriffs-Token verwenden. Sobald das Token abgelaufen ist, können Sie das Aktualisierungstoken verwenden, um ein neues Zugriffstoken zu erhalten. Die Methode in ADAL, die Sie für diesen Zweck verwenden möchten, ist AcquireTokenByRefreshToken .
Nachdem Sie das gesagt haben, sollten Sie in Ihrer Anwendung keine starke Abhängigkeit von Refresh Token eingehen. Basierend auf den beschriebenen Best Practices here kann ein Aktualisierungstoken ablaufen oder ungültig gemacht werden. Darüber hinaus basierend auf Vittorios post , wird in ADAL Version 3 nicht einmal ein Aktualisierungstoken zurückgegeben. Sie sollten dies also berücksichtigen.
Andere Vorgehensweise - Beschlagwortlos erfassen
Sie könnten auch ein neues Token im Namen des Benutzers erwerben, sobald das Token abgelaufen ist. Ich glaube, das erfordert, dass sich ein Benutzer mindestens einmal in Ihrer Anwendung manuell anmelden und dem OAuth2-Flow folgen muss. Die Methode, die Sie verwenden möchten, ist AcquireTokenSilent .
Hier ist der Pseudocode für unseren Ansatz:
%Vor%Tags und Links asp.net-mvc azure c#