Fortsetzung der Diskussion aus OIDC-Anmeldung über die Discourse iOS-App schlägt gelegentlich mit csrf_detected beim Callback fehl:
Hallo zusammen,
Dies ist eine Folgebeobachtung, die mit meinem früheren Thread über OIDC-Anmeldungsfehler zusammenhängt, die von iOS-In-App-Browsern ausgelöst werden. In dieser Diskussion ging es um deterministische csrf_detected-Fehler, die durch die Cookie-Isolierung von WKWebView verursacht werden und die jetzt gut verstanden und erwartet werden.
Dieses verlinkte Thema befasst sich mit der Klarheit für Betreiber, nicht mit einem Fehler.
Beobachtung
Bei der Untersuchung einer Reihe von OIDC-Anmeldungsfehlern habe ich festgestellt, dass dieselbe sichtbare Fehlermeldung in Discourse:
/auth/oidc/callback → /auth/failure?message=csrf_detected
mehreren, grundlegend unterschiedlichen vorgelagerten Ursachen entsprechen kann, abhängig davon, was der IdP zurückgegeben hat.
Allein anhand der Anwendungsoberfläche sind diese Fälle nicht zu unterscheiden. Der Unterschied ist nur durch die Überprüfung von Admin → Logs → env / params sichtbar.
In der Praxis beobachtete Beispiele (Azure / Entra ID)
Zusätzlich zum Verlust von Cookies im In-App-Browser habe ich Callbacks beobachtet, bei denen Entra ID explizit strukturierte Fehler zurückgibt, wie zum Beispiel:
Benutzer hat der Zustimmung verweigert
error=consent_required
error_description=AADSTS65004: User declined to consent to access the app
Benutzer hat die Anmeldung abgebrochen
error=access_denied
error_subcode=cancel
In beiden Fällen:
\t•\tAzure hat den Benutzer erfolgreich identifiziert
\t•\tDer Benutzer hat sich explizit entschieden, nicht fortzufahren (abgelehnt / abgebrochen)
\t•\tDiscourse empfängt den Callback
\t•\tDer Ablauf führt letztendlich zu /auth/failure?message=csrf_detected
Aus Sicht von Discourse ist dies ein korrektes und sicheres Verhalten – der Status kann nicht validiert oder abgeschlossen werden –, aber der zugrunde liegende Grund unterscheidet sich stark von einem fehlenden Sitzungscookie.
Warum das für Betreiber wichtig ist
Ohne die Überprüfung der Log-Umgebung/Parameter könnte ein Administrator, der wiederholte csrf_detected-Fehler sieht, vernünftigerweise annehmen:
\t•\tfehlerhafte Cookies
\t•\tSameSite-Fehlkonfiguration
\t•\tProbleme mit mobilen Browsern
\t•\tIdP-Instabilität
…obwohl einige dieser Fehler tatsächlich darauf zurückzuführen sind, dass Benutzer sich einfach entschieden haben, keine Zustimmung zu geben oder die Microsoft-Aufforderung abzubrechen.
Dieser Unterschied wird nur dann deutlich, wenn man bereits weiß, dass man die rohe Log-Nutzlast überprüfen muss.
Vorschlag (nur Dokumentation / UX)
Ich schlage keine Verhaltensänderung für OmniAuth oder die CSRF-Behandlung vor.
Es wäre hilfreich, wenn die Dokumentation oder die Fehlerbehebung ausdrücklich darauf hinweisen würde, dass:
\t•\tcsrf_detected der Endfehler für mehrere vorgelagerte IdP-Ergebnisse sein kann
\t•\teinschließlich expliziter Benutzeraktionen wie Abbruch oder Verweigerung der Zustimmung
\t•\tund dass Administratoren Admin → Logs → env / params überprüfen sollten, um diese Fälle zu unterscheiden
Dies würde es Betreibern erleichtern:
\t•\tAnmeldefehler korrekt zu diagnostizieren
\t•\tunnötige Konfigurationsänderungen zu vermeiden
\t•\tund Benutzern genaue Anweisungen zu geben („Sie haben abgebrochen / Zustimmung verweigert“ vs. „Ihr Browser hat Cookies blockiert“).
Kontext
Zur Klarstellung: Dies ist getrennt von dem bestätigten Problem mit dem iOS In-App-Browser, das im verlinkten Thema diskutiert wird. In diesem Fall erreicht der IdP nie den Punkt der Benutzerzustimmung, während hier der IdP explizit die Absicht des Benutzers meldet.
Beide sehen auf UI-Ebene ähnlich aus, es sei denn, die Protokolle werden untersucht.
Vielen Dank fürs Lesen – dies wird hauptsächlich als Klarstellung der Dokumentation/Datenpunkt für andere veröffentlicht, die OIDC in Umgebungen mit vielen Studenten betreiben, in denen diese Fälle häufig auftreten.
Gerne stelle ich anonymisierte Beispiele zur Verfügung, falls dies nützlich ist.