Jwt-auth: Aktualisierte Token Flow-UX

Vielen Dank, dass Sie sich die Zeit genommen haben, dies alles aufzuschreiben. Wenn Sie der Meinung sind, dass alles, was folgt, hart ist, ist dies nicht beabsichtigt, ich gebe Ihnen nur meine Meinung und ist nicht die einzige, es gibt wahrscheinlich eine Mischung aus ihnen und die Debatte ist in Ordnung.

Ich befürchte, dass diese Änderung die Funktionalität dieses Plugins für die meisten nicht technisch versierten Benutzer unzugänglich macht, die erwarten, dass sie sich mit ihrem Benutzernamen und ihrem Passwort anmelden können.

Ich verstehe, was Sie hier sagen wollen, aber gleichzeitig schlagen Sie vor, dass es für technisch nicht versierte Benutzer, die ein Token generieren möchten, irgendwie zu schwierig ist, von einem Benutzer zu verlangen, sich bei WordPress anzumelden und ein Schlüsselpaar zu erstellen über die REST-API programmgesteuert. Ich würde argumentieren, dass dies überhaupt keine _nicht-technischen_ Benutzer sind.

Außerdem gibt es in jedem sicheren System Zugangsbarrieren, die der Benutzer überwinden muss, um es zu benutzen. Google erlaubt Ihnen nicht, eine JWT- oder OAuth-Verbindung herzustellen, indem Sie Ihren Nutzernamen und Ihr Passwort in der API-Anfrage verwenden. Das ist nicht sicher. Es muss eine Möglichkeit geben, sicherzustellen, dass ein Token oder eine Authentifizierungsverbindung einem Benutzer auf eine Weise zugeordnet wird, die ungültig gemacht werden kann.

Es ist nicht intuitiv
Jedes andere System, das diese Methode zur Integration in WordPress verwenden möchte, benötigt eine Erklärung/Anleitung zum Einrichten eines Schlüsselpaars, um loszulegen.

Um ein sicheres Modell zu haben, das die Trennung von Zugang und Authentifizierung unterstützt, müssen Sie über Leitplanken verfügen, die verhindern, dass langlebige Token zu einem unendlichen Zugangspunkt werden. Durch das Hinzufügen von Aktualisierungstoken könnte ein böswilliger Benutzer ein Zugriffs- und Aktualisierungstoken mit einer user:pass Kombination erstellen, die wir niemals ungültig machen könnten, wenn kein Schlüsselpaar oder ein Äquivalent vorhanden wäre, um die Token ungültig zu machen.

Dem Benutzer zu sagen, dass er sich bei WordPress anmelden und zu seinem Profil gehen soll, um ein Schlüsselpaar zu generieren, ist ein kleiner Preis für die Sicherheit. Außerdem sind die Anweisungen sehr einfach.

Es ist schwierig, zwischen Geräten zu verwenden
Wenn ich diesen Schlüssel für eine App auf meinem Telefon verwenden möchte, gibt es keine einfache Möglichkeit, ihn dorthin zu bringen. Ich möchte auf meinem Telefon keine langen Zeichenfolgen aus Buchstaben, Zahlen und Sonderzeichen eingeben – wahrscheinlich mache ich einen Transkriptionsfehler. Wir können den Schwierigkeitsgrad der Transkription entfernen, indem wir einen QR-Code generieren, den die Leute scannen können, aber dann kommen wir auf das obige Problem zurück – Leute müssen möglicherweise eine QR-Code-App herunterladen oder Entwickler von Drittanbietern müssen einen QR-Code erstellen Parsen der Bibliothek in ihre App, um mit uns zusammenzuarbeiten.

Bitte beschreiben Sie diese App, auf die Sie sich immer wieder beziehen. Warum sollte sie die gesamte Authentifizierung und Anmeldung für Sie übernehmen? Das ist nicht sicher. Sie würden dieser App den gesamten Zugriff und die Authentifizierung geben, die sie benötigt, um alles, was sie will, mit Ihrer Website zu tun. Sie sollten bedenken, dass die App-Architektur möglicherweise falsch ist und dieser Authentifizierungsablauf genau das verhindern soll, was Sie beschreiben.

Was Sie mir beschrieben haben, ist eine App, die Ihren Klartext-Benutzernamen und Ihr Passwort speichert, damit sie sich über die REST-API bei WordPress anmelden kann, um ein Token zu generieren, das für den Zugriff auf Ressourcen verwendet wird, aber auch vollständig in der Lage ist, Ihre Datenbank über dieselbe zu speichern Authentifizierungs- und Zugangsmittel. Ich verstehe nicht, warum wir etwas unterstützen möchten, das diesem Anwendungsfall, wie Sie ihn beschrieben haben, auch nur annähernd nahe kommt.

Es fördert keine gute Sicherheitshygiene
Im Idealfall würden Benutzer ihre Schlüssel sorgfältig pflegen, um sicherzustellen, dass keiner veraltet, nicht kompromittiert usw. ist. Leider können wir uns nicht darauf verlassen, und kompromittierte Schlüssel sind noch gefährlicher als kompromittierte Token. Es ist auch wahrscheinlich, dass ein durchschnittlicher Benutzer jedes Mal einen neuen Schlüssel erstellt, wenn er einen braucht, anstatt das Geheimnis an einem sicheren Ort zu speichern.

Erstens sind Schlüsselpaare nicht an ein Ablaufdatum angehängt und das einzige, was sie im Moment tun können, ist Tokens zu erstellen, daher kann ich nicht erkennen, wie sie _gefährlicher_ sind als ein kompromittiertes Token, da sie dieses Token ungültig machen. Zweitens tun Benutzer nichts sorgfältig, und wir sollten nie von ihnen erwarten, dass sie die Auswirkungen ihrer Handlungen auf die Sicherheit verstehen. Wir müssen davon ausgehen, dass sie extrem inkompetent und wahrscheinlich faul genug sind, um nie hinter sich aufzuräumen. Das Erstellen zusätzlicher Schlüsselpaare ist jedoch kein Sicherheitsproblem. Das Sicherheitsproblem besteht darin, Ihren Klartext-Benutzernamen und Ihr Passwort an eine fremde App weiterzugeben.

Außerdem – ich bin besorgt darüber, eine zusätzliche Methode zum Widerrufen von Sitzungen hinzuzufügen – WordPress hat bereits eine Schaltfläche „Überall abmelden“ auf der Profilseite – als Benutzer würde ich erwarten, dass mich dies auch von allen Anwendungen abmeldet ( oder mich zumindest fragen, ob ich das machen möchte?)

Wir können den Benutzer auffordern, seine Schlüsselpaare zu löschen, aber ich würde nie erwarten, dass ein Abmelden mein Token zerstört. Das ist nicht das normale oder erwartete Verhalten eines solchen Systems und würde wahrscheinlich zu Chaos und Tonnen von Supportanfragen führen.

Es bietet keine zusätzliche Sicherheit
Wenn ich als Angreifer bereits Ihren Benutzernamen und Ihr Passwort habe, gibt es nichts, was ich nicht als Sie tun kann (vorausgesetzt, es gibt keine 2FA).

Ich stimme kategorisch nicht zu. Dieser Ansatz bietet zusätzliche Sicherheit für den Zugriff auf Ihre REST-Ressourcen. Wenn dies nicht offensichtlich ist, benötigen wir weitere Dokumentation, um dies zu verdeutlichen. Sie argumentieren, dass, wenn jemand Ihre Anmeldeinformationen bereits hat, Sie am Arsch liegen, aber Sie schlagen auch vor, dass wir sie verwenden, um Zugriff auf die REST-API zu gewähren. Wenn Sie so auf REST zugreifen möchten, verwenden Sie Basic Auth. Denn genau das würden wir implementieren, wenn wir user:pass zum Erstellen von Token verwenden.

Dies führt dazu, dass ich, wenn ich als unerfahrener Anwendungsentwickler das Leben meines Benutzers erleichtern möchte, möglicherweise etwas Unratsames probiere, z ziehe sie zurück in meine App.

Hier möchten wir einen Authentifizierungsablauf erstellen, der es ermöglicht, einer App das Schlüsselpaar durch die Verwendung eines Rückrufs zu geben. Ich glaube, so etwas wurde bereits im Plugin für Anwendungskennwörter implementiert.

Ich bin zu 100% offen für die Erstellung eines Authentifizierungsflows für Apps, bei denen Sie aufgefordert werden, sich bei WordPress anzumelden, mit zusätzlichen Extras wie 2factor, die ein Schlüsselpaar für Sie generieren und dann eine Art Rückruf verwenden Geben Sie der App das Schlüsselpaar. Dann müssen App-Entwickler keine Unmengen an schlechten Lösungen erstellen und die App speichert ihre user:pass .

Was könnte stattdessen getan werden?
Der Schlüssel dient derzeit einem wichtigen Zweck – er wird verwendet, um den Widerruf eines Tokens zu ermöglichen, obwohl Token möglicherweise sehr langlebig sind. Dafür benötigen wir jedoch nicht unbedingt ein Schlüsselpaar.

Richtig, Sie können viele verschiedene Ansätze verwenden.

Inspiriert vom WordPress-Eintrag session_tokens in usermeta – ein gespeicherter Satz von JWT-spezifischen Widerrufsschlüsseln würde die gleiche Funktionalität ermöglichen, und es wäre trivial, die Funktion „Überall abmelden“ zu implementieren – löschen Sie einfach diesen Eintrag aus der Tabelle.

Dies würde niemals die aktuelle Implementierung ersetzen, zu der es zusätzlich sein müsste. Als Entwickler von Unternehmenssoftware würde ich diese Methode niemals verwenden. Obwohl es sich um einen gültigen Ansatz handelt, kann jedoch nicht erwartet werden, dass ein Token gültig ist, solange er nicht abgelaufen ist oder der Token nicht widerrufen wird. In Ihrem Szenario ist das Token in der Sekunde, in der Sie sich abmelden, ungültig. Dies wäre IMO ein Mangel im Authentifizierungsfluss, der unzählige Probleme mit der Fähigkeit meiner Apps verursachen würde, Ressourcenzugriff zu erhalten, da er jetzt eng an den angemeldeten Benutzer gekoppelt ist.

Was ist mit 2FA?
Ich frage mich, ob es möglich sein könnte, einen Hook zuzulassen, den 2FA-Plugins verwenden könnten, um dem Client mitzuteilen, dass "Bitte versuchen Sie es erneut und geben Sie ein 2FA-Token an", wenn eines erforderlich, aber nicht bereitgestellt wurde. Darüber hinaus könnte ein anderer Hook (oder vielleicht der gleiche?) verwendet werden, um dem 2FA-Plugin zu ermöglichen, zu überprüfen, ob der bereitgestellte Code korrekt ist? Das JWT-System würde keine Annahmen über die Implementierung von 2FA machen – das wäre einem anderen Plugin überlassen – wir würden nur die Hooks bereitstellen, um so etwas zu ermöglichen.

Dies würde IMO eine unnötige Komplexitätsebene hinzufügen, die das Potenzial hat, viele Supportanfragen zu erstellen.

Vielen Dank, dass Sie bis hierhin gelesen haben – alles oben Genannte ist IMHO, aber ich hoffe, wir können diesen Prozess für die Benutzer ein wenig vereinfachen, damit er für alle sofort einsatzbereit ist.

Ich bin mir sicher, dass ich zumindest etwas verpasst habe, daher freue ich mich über jedes Feedback, das die Leute dazu haben!

Epischer Beitrag. Vielen Dank, dass Sie sich die Zeit genommen haben, dies alles aufzuschreiben. Du hast dir wirklich viele Gedanken gemacht. Ich möchte sagen, dass ich nicht versuche, etwas abzuschießen. Nur wenn wir zulassen, dass Token mit einer user:pass Kombination erstellt werden, muss die Art und Weise, wie wir dies tun, sehr, sehr sicher sein und kein Potenzial für Apps haben, Ihre Anmeldeinformationen zu speichern.

Die Trennung von Zugang und Authentifizierung ist sinnvoll und sollte nicht auf die leichte Schulter genommen werden. Wir bauen die potenzielle REST-Authentifizierung für 1/3 des Internets auf. Bis wir einen Weg nach vorne haben, habe ich die Möglichkeit entfernt, Token mit Benutzeranmeldeinformationen zu erstellen. Das bedeutet nicht, dass wir es nicht wieder hinzufügen können, nur dass es vorher viel Diskussion bedarf.

Hi! Soweit ich weiß, ist der Hauptproblempunkt bei der Konversation hier die Benutzerfreundlichkeit. Tatsächlich wird es für einige Benutzer eine Quelle von Problemen oder Unannehmlichkeiten sein, wenn Benutzer auf die Site gehen, um sich anzumelden und die Schlüsselpaare zu erstellen.

Entwickler werden wahrscheinlich versuchen, ungesicherte Wege zu finden, um zu vermeiden, dass sie heute Funktionen entfernen, die zum Wohle ihrer Benutzer starke Passwörter erfordern.

Obwohl ich den Sicherheitsaspekt in der Entscheidung verstehe und irgendwie zustimme. Aber wir müssen einen Weg finden, der für beides funktioniert.

Es scheint, dass das, was Sie hier @valendesigns gesagt haben, eine mögliche Lösung sein könnte:

Ich bin zu 100% offen für die Erstellung eines Authentifizierungsflows für Apps, bei denen Sie aufgefordert werden, sich bei WordPress anzumelden, mit zusätzlichen Extras wie 2factor, die ein Schlüsselpaar für Sie generieren und dann eine Art Rückruf verwenden Geben Sie der App das Schlüsselpaar. Dann müssen App-Entwickler keine Unmengen an schlechten Lösungen erstellen und die App speichert ihren user:pass nicht.

Soweit ich weiß, würden wir im Grunde den aktuellen Fluss beibehalten, was sicherer ist, da wir unser Passwort nicht an die App weitergeben müssen, sondern nur das Schlüsselpaar zum Generieren des Tokens, aber das könnte für einige eine Hürde sein .

Behalten Sie diesen anderen Fluss bei, bei dem wir unser Passwort nicht an die fremde App weitergeben müssen. Stattdessen bitten Sie sie, sich bei WordPress anzumelden und das Schlüsselpaar zu generieren.

Ich hätte gerne mehr Informationen zu diesem Teil:

Wir können den Benutzer auffordern, seine Schlüsselpaare zu löschen, aber ich würde nie erwarten, dass ein Abmelden mein Token zerstört. Das ist nicht das normale oder erwartete Verhalten eines solchen Systems und würde wahrscheinlich zu Chaos und Tonnen von Supportanfragen führen.

Es erscheint, wenn ich über den Browser und die App auf site.com eingeloggt bin, wenn ich im Browser auf "Überall abmelden" klicke, würde ich mich auch in der App abmelden, oder?! Ich kann Apps sehen, bei denen dies die Annahme wäre. Die Erwartung, dass Sie überall abgemeldet werden.

Das gleiche müsste passieren, wenn ein Konto gelöscht wird.

Ich muss dem zustimmen, was gesagt wurde, dass das Schlüsselpaar UX sehr benutzerfreundlich ist.

Es macht es sehr schwierig, eine native mobile App zu erstellen, die diese Auth-Methode verwenden kann.

• Ich hatte vor einiger Zeit ein benutzerdefiniertes Plugin für das (alte) OAuth1a-Plugin erstellt, das einen verschlüsselten (mit einem kurzen, einstellbaren Passwort) QR-Code auf der Anwendungsverwaltungsseite anzeigte (wenn der App-Name und die Rückruf-URL mit meiner Anwendung übereinstimmten), was dann übergab die Client-App-Informationen an die mobile App, um dem Benutzer dann die Authentifizierung zu ermöglichen.

Zugegeben (Wortspiel beabsichtigt), JWT ist viel einfacher als OAuth1a ;)

Da sich ein Benutzer zuerst bei Wordpress (hoffentlich über https) mit einem Benutzernamen und einem Passwort anmelden muss, sehe ich wirklich nicht das Sicherheitsproblem, wenn das Benutzername/Passwort-Paar ein Zugriffstoken erhalten kann ? Alles wird am Ende des Tages über den gleichen „Draht“ gesendet? Sicherlich?

Das Erzwingen des derzeit implementierten Anwendungsschlüsselpaares macht diese Authentifizierungsmethode (in der realen Welt) für mobile Anwendungen absolut unmöglich.

Es gibt einfach keine vernünftige Möglichkeit, eine mobile App zu bekommen, um sie einzugeben.

Ich habe OAuth1a, OAuth2 und jetzt zwei JWT-Plugins ausprobiert, um meine nativen Apps mit Zugriff zu implementieren, und alle schlagen 'out-of-the-box' fehl, ohne etwas herumzuhacken, um zu versuchen, die Dinge für einen Benutzer zum Laufen zu bringen. Das Zeug soll doch einfacher werden?

Das JWT-Plugin von Drittanbietern (mit mehr als 10.000 Installationen) unterstützt Benutzer/Pass und funktioniert gut für eine native mobile Anwendung, die ich erstellt habe. Es schlägt jedoch fehl, weil über das Plugin keine Aktualisierungstoken vorhanden sind, wodurch der Benutzer gezwungen wird, sich erneut anzumelden. (es erfordert auch die manuelle Bearbeitung von wp-config)

Dieses 'bald offiziell' (hoffe ich!) Plugin scheitert an der mangelnden Benutzerfreundlichkeit für Mobilgeräte und an der scheinbaren Ignoranz, welche Art von Anwendungen realistisch dafür entwickelt werden können. Und das scheint sehr kurzsichtig.

Es gibt einen Grund, warum es an nativen mobilen Apps zum Posten auf wp.org-Sites mangelt. Und das ist es.

Bitte, bitte, können wir etwas bewegen? (Ich arbeite seit Jahren an einer nativen App und warte seit der Einführung der REST-API auf eine "richtige" Methode zur Authentifizierung von Benutzern.)

:)

Die Token Flow UX ist verrückt und unpraktisch für die reale Nutzung, Benutzer sollten sich mit Benutzernamen und Passwort am System anmelden können, nach einem API-Schlüsselpaar zu fragen, macht keinen Sinn, Sie verwenden hier keine Abstraktion, Sie werden angenommen Um Benutzer vor den technischen Details der Verwendung Ihrer Anwendung zu schützen, wie werden Sie das Gefühl haben, dass Sie sich bei einem Admin-Portal auf Facebook anmelden und ein API-Schlüsselpaar erstellen und dann das API-Schlüsselpaar verwenden müssen, um sich auf Ihrem Telefon bei Facebook anzumelden? einloggen, wir entwickeln nicht für Entwickler, wir entwickeln für den Kunden, der nicht weiß, was der technische Aspekt Ihres Dienstes ist, sofort deinstallieren. Ich sehe wirklich nicht, wie dieses Plugin für die Authentifizierung nützlich ist.

Dieses Problem mit Benutzeranmeldung > Token-Flow hält die Entwicklung SO vieler Apps, die JWT verwenden könnten, ernsthaft auf.

Monate und Monate vergehen und es wird einfach nicht angesprochen.

Wie ich oben sagte, lässt die Tatsache, dass Benutzer ein Benutzername/Passwort-Paar verwenden, um sich tatsächlich bei Admin anzumelden, irgendein Argument dafür, keine Benutzername/Passwort-Paare zu verwenden, um ein Token zu erhalten, etwas ungültig erscheinen? Sicherlich?

Nur um diesen Thread zu aktualisieren – es hört sich so an, als würde dieses Projekt von einem ersetzt, um einen vollständigen OAuth-Flow im WP-Kern zu implementieren. Es sollte die Nachteile der hier diskutierten Ansätze adressieren und gleichzeitig alle Stärken beibehalten.

Wenn du dich daran beteiligen möchtest, kannst du gerne in