Jwt-auth: [question] Cas d'utilisation de l'API sans tête

Créé le 12 déc. 2019 · 3Commentaires · Source: WP-API/jwt-auth

L'architecture du flux d'authentification dans ce plugin est excellente ; Je comprends les soucis de sécurité. Bien qu'il désactive peut-être le principal cas d'utilisation d'une telle fonctionnalité : Wordpress en tant que CMS sans tête.

Désactive l'authentification CMS sans tête

Un CMS sans tête exigerait que les utilisateurs se connectent via username et password . Une fois que l'utilisateur dispose d'un JWT, il peut envoyer des requêtes authentifiées à des ressources protégées. Dans un environnement CMS sans tête, il serait prohibitif et contre-intuitif de demander aux utilisateurs de générer des jetons d'API.

La sécurité doit être mise en œuvre via les privilèges RBAC, les rôles et les responsabilités des utilisateurs dictant ce qui est protégé dans l'API. Les problèmes de sécurité pourraient être atténués par des valeurs par défaut très strictes de RBAC. Wordpress a déjà un excellent cadre de rôles et de responsabilités.

Pour résoudre les problèmes de sécurité réels :

Des jetons de longue durée ? Faites-en des jetons de courte durée.
Vous craignez que des jetons à longue durée de vie puissent être volés ? Il en va de même pour les jetons d'API, argument nul.
Les meilleures pratiques JWT dictent la courte durée de vie tokens et la longue durée de vie refresh_tokens (les jetons d'actualisation sont révocables). C'est donc plus sûr que de distribuer des jetons d'API à durée de vie infinie qui peuvent être perdus.

N'est-ce pas juste OAuth2 ?

Cette approche est essentiellement un scénario d'attribution de jeton oAuth2 "personal access" . Ainsi, je remettrais en question les mérites d'une approche de serveur d'authentification de jeton personnalisée comme celle-ci par rapport à une implémentation standard oAuth2 appropriée ? Si la sécurité est la principale préoccupation ici, alors cette approche présente en fait des risques de sécurité ? par exemple, une implémentation testée au combat d'oAuth2 telle que php-league-oatuh-2

Je vois le seul cas d'utilisation viable pour le flux d'authentification actuel application-to-application ? oAuth2 présente plusieurs méthodes de flux d'authentification pour accorder des jetons. L'un étant ce que cette approche utilise "personal access" et l'autre étant ce que je décris "password access" jetons. Une implémentation complète d'oAuth2 permettrait ces deux scénarios et plus encore...

Plus loin

Nous pensons que l'adoption de WP-API et donc la modernisation de l'écosystème Wordpress en général seraient grandement améliorées si des éléments tels que l'authentification d'API sans état étaient facilement accessibles aux développeurs.

Ce ne sont que des réflexions et j'aimerais discuter et contribuer !

Bon travail!

équipe sans tête wp

Source

andrewmclagan

👍3 🚀1 ❤1

Commentaire le plus utile

J'ai créé des applications natives (ou essayé de le faire) avant que l'API REST ne soit intégrée au cœur. (c'est-à-dire : années)

Initialement, le seul moyen pour mon application de s'authentifier et de télécharger/créer du contenu était d'utiliser le plugin 'OAuth1.0a' que l'équipe API a lancé.

J'ai maintenant des choses qui fonctionnent pour OAuth2.0 (encore une fois, une autre fonctionnalité qui nécessite l'installation d'un plugin supplémentaire. Aucune idée si cela va jamais arriver au cœur)

Et maintenant, nous avons JWT qui présente de nouveaux problèmes pour connecter mon application. Naturellement, un nom d'utilisateur/mot de passe fonctionnerait mieux, fournissant un jeton. (Heureusement, cette version 'WP-API' de JWT prend en charge l'actualisation des jetons. Un autre plugin JWT largement utilisé ne le fait pas)

Je ne peux pas croire la quantité d'opportunités (et de temps) perdues qui s'écoulent, sans avoir une implémentation solide "sans tête"/mobile pour l'authentification "prête à l'emploi" (dans le noyau).

Mon application mobile nécessite son propre plug-in pour faire son travail et prendre en charge une charge d'éléments liés à l'administration et d'améliorations d'itinéraire. blocs personnalisés, etc. Je préférerais ne pas avoir à obliger les utilisateurs/clients de mon application à télécharger et à installer un autre plugin "pas tout à fait fini".

Je souhaite juste qu'une solution solide (et «officielle») existe.

kosso le 17 déc. 2019

👍3

Tous les 3 commentaires

J'ai créé des applications natives (ou essayé de le faire) avant que l'API REST ne soit intégrée au cœur. (c'est-à-dire : années)

Initialement, le seul moyen pour mon application de s'authentifier et de télécharger/créer du contenu était d'utiliser le plugin 'OAuth1.0a' que l'équipe API a lancé.

Je souhaite juste qu'une solution solide (et «officielle») existe.

kosso le 17 déc. 2019

👍3

Je suis entièrement d'accord. Wordpress est positionné pour devenir un leader dans le domaine des cms sans tête. Il semble que l'équipe principale fasse des progrès dans ce domaine, mais peut-être uniquement pour servir un cas d'utilisation spécifique pour wordpress.com ? Pas certain.

Nous développons actuellement un client isomorphe à cet effet. Avec les hooks et les fournisseurs de réaction. https://github.com/wp-headless/fetch. Peut-être allons-nous devoir écrire notre propre plugin d'authentification JWT. Mes réflexions sur ce à quoi cela devrait ressembler:

Suivez les spécifications oAuth2 (pourquoi créer un flux d'authentification personnalisé ?)
Avoir plusieurs méthodes d'octroi de jetons : password , machine-to-machine , api-key etc.
dépendent des principaux packages qui sont bien testés.

andrewmclagan le 18 déc. 2019

Ici, je suis coincé à essayer d'implémenter un système d'enregistrement/d'authentification des utilisateurs via l'API WP REST, seulement pour découvrir que l'équipe WP ~~réinvente la roue~~ en inventant une nouvelle roue.