OWIN OpenIdConnect Middleware IDX10311 kann nicht geprüft werden
Ich habe eine Anwendung, die die OWIN-Middleware für OpenIdConnect verwendet. Die Datei startup.cs verwendet die Standardimplementierung von app.UseOpenIdConnectAuthentication. Der Cookie ist auf den Browser gesetzt, aber er wird mit folgenden Fehlern angezeigt:
IDX10311: RequireNonce ist 'true' (Standard), validationContext.Nonce ist jedoch null. Ein Nonce kann nicht bestätigt werden. Wenn Sie die Nonce nicht überprüfen müssen, setzen Sie OpenIdConnectProtocolValidator.RequireNonce auf 'false'.
Ich habe festgestellt, dass dieses Verhalten beim Ausführen von Fiddler wie bei den meisten Debug-Projekten auftritt. Der Fehler wird zurückgegeben, aber wenn ich zur Website zurück gehe, funktioniert alles und mein Benutzer wird authentifiziert. Hat jemand dieses Verhalten beim Laufen von Fiedlern gesehen?
Mit Fiedler:
- Die SecurityTokenValidated-Benachrichtigung in OpenIdConnect wird zweimal ausgeführt.
- Nach dem zweiten Durchlauf wird der IDX10311-Fehler ausgegeben
- Der Browser enthält den gültigen Cookie. Zurück zur Seite, in der ich die gültigen User.Identity-Daten anzeigen kann.
Laufen ohne Fiedler:
- SecurityTokenValidated wird einmal in OpenIdConnect ausgeführt
- Es wird kein Fehler ausgegeben, die Controller-Aktion wird nach Uri für die Umleitung nach der Authentifizierung geladen
- Cookie auch gültig und User.Identity-Daten korrekt.
Ideen? Ich kann es umgehen, ohne Fiddler zu laufen, aber beim Debuggen wäre es schön, auch Fiddler zu laufen, um den Verkehr zu untersuchen.
Ich hatte das gleiche Problem, aber das Zurücksetzen des Microsoft.Owin.Security.OpenIdConnect auf Version 3.0.1 löste das Problem
Vielleicht ist das die Ursache?
Hallo, ich glaube, ich habe die Ursache für dieses Problem gefunden.
Ich fasse meine Entdeckungen zusammen:
Das Problem befindet sich im Cookie "OpenIdConnect.nonce.OpenIdConnect"
Dieses Cookie wird von der App aus gesetzt (nennen wir diesen "ID-Client"), sobald die OpenID Middleware eine Authentifizierungssitzung initiiert
Das Cookie sollte vom Browser an den "ID Client" zurückgeschickt werden, sobald die Authentifizierung abgeschlossen ist. Ich gehe davon aus, dass dieses Cookie für eine doppelte Überprüfung aus Sicht des ID-Clients erforderlich ist (d. H. Habe ich wirklich einen OpenID Connect-Berechtigungsfluss gestartet?).
Viele Verwirrung in mir wurde durch den Begriff "Nonce" verursacht, der sowohl in diesem Cookie als auch im OpenID Connect-Fluss vom ID-Server verwendet wird.
In meinem Fall wurde die Ausnahme durch den fehlenden Cookie verursacht (nicht durch den ID-Server), nur weil er vom Browser nicht an den "ID-Client" zurückgesendet wurde.
Die Hauptwurzel in meinem Fall war also Folgendes: Das OpenIdConnect.nonce.OpenIdConnect-Cookie wurde vom Browser nicht an den ID-Client zurückgesendet. In einigen Fällen (z. B. Chrome, Firefox und Edge) wurde das Cookie richtig gesendet, in anderen (IE11, Safari) jedoch nicht.
Nach langen Recherchen entdeckte ich, dass das Problem in der Cookie-Einschränkungsrichtlinie lag, die im Browser definiert wurde. In meinem Fall ist der "ID-Client" in einen <iframe> eingebettet. Dies führt dazu, dass der "ID-Client" als "Drittanbieter-Client" betrachtet wird, da der Benutzer nicht direkt im Hauptfenster zu dieser URL navigiert wurde. Da es sich um einen Drittanbieter handelt, müssen die Cookies für einige Browser blockiert werden .. In der Tat kann derselbe Effekt in Chrome erzielt werden, indem "Drittanbieter-Cookies blockieren" eingestellt wird.
Also muss ich folgern:
a) Wenn iframe ein Muss ist (wie in meinem Fall, da "ID Clients" Apps sind, die im Grafikinhalt unserer Hauptplattform-App ausgeführt werden müssen), denke ich, dass die einzige Lösung darin besteht, den Fehler abzufangen und damit umzugehen eine Seite, die den Benutzer auffordert, Cookies von Drittanbietern zu aktivieren.
b) Wenn iframe kein Muss ist, reicht es aus, den "ID Client" in einem neuen Fenster zu öffnen.
Hoffe das hilft jemandem, weil ich verrückt geworden bin!
Marco
Ich weiß, es ist ein alter Beitrag, aber ich hatte dieses Problem und nichts funktionierte für mich. Nachdem ich meinen Verstand hinter einer Lösung verloren hatte, um meine Unternehmensanwendung zum Laufen zu bringen, beendete ich das Problem, indem ich die Option für mehrere Mandanten in Azure auf yes (in Azure) setzte Wählen Sie: App-Registrierung> Einstellungen> Eigenschaften, setzen Sie Multi-Mandanten auf Ja und klicken Sie auf Speichern.
hoffe, es hilft jemandem, konnte niemand sehen, der es erwähnt.
Das Ändern der Antwort-URL in Azure Active Directory funktioniert für mich.
Dies geschieht, wenn Sie SSL aktivieren, da nur die Anmelde-URL in die HTTPS-URL geändert wird, während die Antwort-URL dieselbe HTTP-URL bleibt.
Wenn Sie versuchen, über die https-URL auf Ihre App zuzugreifen, wird ein Cookie mit einer eindeutigen Nummer (Nonce) in Ihrem Browser gesetzt und zur Authentifizierung wird Azure AD angezeigt. Nach der Authentifizierung muss der Browser Zugriff auf dieses Cookie gewähren. Da sich die Anmelde-URL und die Antwort-URL jedoch unterscheiden, erkennt der Browser Ihre App nicht und gewährt keinen Zugriff auf das Cookie. Daher gibt die Anwendung diesen Fehler aus.
Eine temporäre Lösung, die für eine über Azure Active Directory gesicherte App für mich funktionierte, bestand darin, sich abzumelden (über die Sites/Konto/SignOut-Seite). Anschließend konnte ich zur Startseite zurückkehren und mich mit OK anmelden. Hoffe das hilft jemandem.
Ich habe diesen Fehler beim Ausführen von IIS Express im Hintergrund bemerkt, als ich auf das IIS-Hosting umgestellt hatte. Wenn ich den IIS Express deaktivierte, verschwand mein Fehler.
Eine Regel zum Umschreiben von Cookies in der Datei "web.config" stellt sicher, dass Cookies auf der gleichen Site diese kryptische Ausnahme darstellen. Durch das Deaktivieren dieser Regel wurde das Problem gelöst.