Jwt-auth: [Frage] Headless-API-Anwendungsfall

Erstellt am 12. Dez. 2019 · 3Kommentare · Quelle: WP-API/jwt-auth

Die Architektur des Authentifizierungsflusses in diesem Plugin ist großartig; Ich verstehe die Sicherheitsbedenken. Obwohl es vielleicht den primären Anwendungsfall einer solchen Funktion deaktiviert: Wordpress als kopfloses CMS.

Deaktiviert die Headless-CMS-Authentifizierung

Bei einem Headless-CMS müssten sich Benutzer über username und password anmelden. Sobald der Benutzer ein JWT hat, kann er authentifizierte Anfragen an geschützte Ressourcen senden. In einer Headless-CMS-Umgebung wäre es unerschwinglich und kontraintuitiv, Benutzer aufzufordern, API-Token zu generieren.

Sicherheit sollte durch RBAC-Berechtigungen, Benutzerrollen und Verantwortlichkeiten implementiert werden, die vorgeben, was in der API geschützt wird. Sicherheitsbedenken könnten durch sehr strenge Standardeinstellungen von RBAC entschärft werden. Wordpress hat bereits ein großartiges Rahmenwerk für Rollen und Verantwortlichkeiten.

Um die eigentlichen Sicherheitsbedenken anzusprechen:

Langlebige Zeichen? Machen Sie sie zu kurzlebigen Token.
Bedenken, dass langlebige Token gestohlen werden können? Das gilt auch für API-Token, Nullargument.
Die Best Practices von JWT schreiben kurzlebige tokens und langlebige refresh_tokens vor (Aktualisierungstoken sind widerruflich). Daher ist dies sicherer als das Ausgeben von unendlich gelebten API-Token, die verloren gehen können.

Ist das nicht nur OAuth2?

Dieser Ansatz ist im Wesentlichen ein oAuth2 "personal access" -Token-Zuteilungsszenario. Daher würde ich die Vorzüge eines benutzerdefinierten Token-Authentifizierungsserveransatzes wie diesem gegenüber einer ordnungsgemäßen oAuth2-Standardimplementierung in Frage stellen? Wenn hier Sicherheit im Vordergrund steht, birgt dieser Ansatz dann tatsächlich Sicherheitsrisiken? zB eine kampferprobte Implementierung von oAuth2 wie php-league-oatuh-2

Ich sehe den einzigen praktikablen Anwendungsfall für die Authentifizierung des aktuellen Authentifizierungsflusses application-to-application ? oAuth2 legt mehrere Auth-Flow-Methoden bereit, um Token zu gewähren. Zum einen verwendet dieser Ansatz "personal access" und zum anderen beschreibe ich "password access" -Token. Eine vollständige oAuth2-Implementierung würde diese beiden Szenarien und mehr ermöglichen ...

Des Weiteren

Wir glauben, dass die Aufnahme der WP-API und damit die Modernisierung des Wordpress-Ökosystems im Allgemeinen erheblich verbessert werden würde, wenn Dinge wie die zustandslose API-Authentifizierung für Entwickler leicht zugänglich wären.

Dies sind nur Überlegungen und würden gerne diskutieren und beitragen!

Gute Arbeit!

wp-headless-Team

Quelle

andrewmclagan

👍3 🚀1 ❤1

Hilfreichster Kommentar

Ich habe schon native Apps erstellt (oder es versucht), bevor die REST-API es zum Kern geschafft hat. (dh: Jahre)

Anfänglich war die einzige Möglichkeit für meine App, Inhalte zu authentifizieren und hochzuladen/erstellen, die Verwendung des Plugins „OAuth1.0a“, das das API-Team gestartet hat.

Ich habe jetzt Dinge, die für OAuth2.0 funktionieren (wieder eine weitere Funktion, für die ein zusätzliches Plugin installiert werden muss. Keine Ahnung, ob dies jemals zum Kern gelangen wird)

Und jetzt haben wir JWT, das neue Probleme mit sich bringt, wie ich meine App verbinden kann. Natürlich würde ein Benutzername/Passwort besser funktionieren, indem ein Token bereitgestellt wird. (Glücklicherweise unterstützt diese 'WP-API'-Version von JWT die Token-Aktualisierung. Ein anderes weit verbreitetes JWT-Plugin tut dies nicht.)

Ich kann die schiere Menge an verlorenen Gelegenheiten (und Zeit) nicht glauben, die vergehen, ohne eine solide „kopflose“/mobile Implementierung für die Authentifizierung „out of the box“ (im Kern) zu haben.

Meine mobile App benötigt ein eigenes Plugin, um ihre Arbeit zu erledigen und eine Menge admin-bezogener Dinge und Routenverbesserungen zu unterstützen. benutzerdefinierte Blöcke usw. Ich möchte meine App-Benutzer/Kunden lieber nicht dazu bringen, ein weiteres "nicht ganz fertiges" Plugin herunterzuladen und zu installieren.

Ich wünschte nur, es gäbe eine solide (und "offizielle") Lösung.

kosso am 17. Dez. 2019

👍3

Alle 3 Kommentare

Ich habe schon native Apps erstellt (oder es versucht), bevor die REST-API es zum Kern geschafft hat. (dh: Jahre)

Anfänglich war die einzige Möglichkeit für meine App, Inhalte zu authentifizieren und hochzuladen/erstellen, die Verwendung des Plugins „OAuth1.0a“, das das API-Team gestartet hat.

Ich habe jetzt Dinge, die für OAuth2.0 funktionieren (wieder eine weitere Funktion, für die ein zusätzliches Plugin installiert werden muss. Keine Ahnung, ob dies jemals zum Kern gelangen wird)

Ich wünschte nur, es gäbe eine solide (und "offizielle") Lösung.

kosso am 17. Dez. 2019

👍3

Ich bin sehr einverstanden. Wordpress ist positioniert, um ein führendes Unternehmen im Headless-CMS-Bereich zu werden. Es scheint, dass das Kernteam darauf eingeht, aber vielleicht nur, um einen bestimmten Anwendungsfall für wordpress.com zu bedienen? Nicht sicher.

Dazu entwickeln wir derzeit einen isomorphen Client. Zusammen mit Haken und Anbietern reagieren. https://github.com/wp-headless/fetch. Vielleicht müssen wir unser eigenes JWT-Authentifizierungs-Plugin schreiben. Meine Gedanken, wie es aussehen sollte:

Befolgen Sie die oAuth2-Spezifikationen (warum einen benutzerdefinierten Authentifizierungsablauf erstellen?)
Haben Sie mehrere Token-Erteilungsmethoden: password , machine-to-machine , api-key usw..
Verlassen Sie sich auf führende Pakete, die gut getestet sind.

andrewmclagan am 18. Dez. 2019

Hier stecke ich mit dem Versuch fest, ein Benutzerregistrierungs-/Authentifizierungssystem über die WP-REST-API zu implementieren, nur um herauszufinden, dass das WP-Team ~~das Rad neu~~ erfindet und ein neues Rad erfindet.

w33zy am 21. Dez. 2019

War diese Seite hilfreich?

0 / 5 - 0 Bewertungen