Jwt-auth: UX de flux de jetons mis à jour

Merci d'avoir pris le temps d'écrire tout cela. Si vous pensez que tout ce qui suit est dur, ce n'est pas censé l'être, je ne fais que vous donner mon avis et ce n'est pas le seul, il y a probablement un mélange d'entre eux et le débat est bon.

Je crains que ce changement ne rende la fonctionnalité de ce plugin inaccessible à la plupart des utilisateurs non techniques, qui s'attendent à pouvoir se connecter en utilisant leur nom d'utilisateur et leur mot de passe.

Je comprends ce que vous essayez de dire ici, mais en même temps, ce que vous suggérez, c'est qu'exiger d'un utilisateur qu'il se connecte à WordPress et qu'il crée une paire de clés est en quelque sorte trop difficile pour les utilisateurs non techniques qui souhaitent générer un jeton. via l'API REST par programmation. Je dirais que ce ne sont pas du tout des utilisateurs _non techniques_.

De plus, dans chaque système sécurisé, il y aura des barrières à l'entrée que l'utilisateur devra surmonter pour l'utiliser. Google ne vous permet pas de créer une connexion JWT ou OAuth en utilisant votre nom d'utilisateur et votre mot de passe dans la requête API. Ce n'est pas sûr. Il doit y avoir un moyen de s'assurer qu'un jeton ou une connexion d'authentification est attaché à un utilisateur d'une manière qui peut être invalidée.

C'est non intuitif
Tout autre système qui souhaite utiliser cette méthode pour s'intégrer à WordPress devra avoir une explication/un didacticiel sur la façon de configurer une paire de clés afin de commencer.

Afin d'avoir un modèle sécurisé qui prend en charge la séparation de l'accès et de l'authentification, vous devez avoir des garde-fous qui empêchent les jetons de longue durée de devenir un point d'accès infini. Avec l'ajout de jetons d'actualisation, un utilisateur malveillant pourrait créer un jeton d'accès et d'actualisation avec une combinaison user:pass que nous ne pourrions jamais invalider s'il n'y avait pas de paire de clés, ou un équivalent, pour invalider les jetons.

Dire à l'utilisateur de se connecter à WordPress et d'aller sur son profil pour générer une paire de clés est un petit prix à payer pour la sécurité. De plus, les instructions sont très simples.

Il est difficile à utiliser entre les appareils
Si j'espère utiliser cette clé pour une application sur mon téléphone, il n'y a pas de moyen facile d'y accéder. Je ne veux pas taper une longue chaîne de lettres, de chiffres et de caractères spéciaux sur mon téléphone – je suis susceptible de faire une erreur de transcription. Nous pouvons supprimer le niveau de difficulté de la transcription en générant un code QR que les gens pourraient numériser, mais nous revenons ensuite au problème ci-dessus : les gens peuvent avoir besoin de télécharger une application de code QR, ou les développeurs tiers devraient créer un code QR bibliothèque d'analyse dans leur application afin de travailler avec nous.

Veuillez décrire cette application à laquelle vous faites constamment référence, pourquoi gérerait-elle toute l'authentification et la connexion pour vous ? Ce n'est pas sûr. Vous donneriez à cette application tout l'accès et l'authentification dont elle a besoin pour faire tout ce qu'elle veut sur votre site Web. Vous devez considérer que l'architecture des applications est peut-être incorrecte et que ce flux d'authentification a pour but d'empêcher la chose exacte que vous décrivez.

Ce que vous m'avez décrit est une application qui stocke votre nom d'utilisateur et votre mot de passe en texte brut afin qu'elle puisse se connecter à WordPress via l'API REST pour générer un jeton utilisé pour accéder aux ressources, mais est également entièrement capable de vider votre base de données via le même moyens d'authentification et d'accès. Je ne vois pas pourquoi nous voudrions prendre en charge quoi que ce soit à distance proche de ce cas d'utilisation comme vous l'avez décrit.

Cela n'encourage pas une bonne hygiène de sécurité
Idéalement, les utilisateurs conserveraient soigneusement leurs clés afin de s'assurer qu'aucune n'est obsolète, sans compromis, etc. Malheureusement, nous ne pouvons pas compter là-dessus, et les clés compromises sont encore plus dangereuses que les jetons compromis. Il est également probable qu'un utilisateur moyen crée une nouvelle clé chaque fois qu'il en a besoin, plutôt que de stocker le secret dans un endroit sûr.

Premièrement, les paires de clés ne sont pas attachées à une date d'expiration et la seule chose qu'elles peuvent faire pour le moment est de créer des jetons, donc je ne vois pas en quoi elles sont _plus dangereuses_ qu'un jeton compromis puisqu'elles sont la chose qui invalide ce jeton. Deuxièmement, les utilisateurs ne font rien avec précaution et nous ne devons jamais nous attendre à ce qu'ils comprennent les implications de sécurité de leurs actions. Nous devons supposer qu'ils sont extrêmement incompétents et probablement assez paresseux pour ne jamais nettoyer après eux-mêmes. Cependant, la création de paires de clés supplémentaires n'est pas un problème de sécurité. Le problème de sécurité serait de donner votre nom d'utilisateur et votre mot de passe en clair à une application étrangère.

De plus - je suis préoccupé par l'ajout d'une méthode supplémentaire pour révoquer des sessions - WordPress a déjà un bouton "Se déconnecter partout ailleurs" sur la page de profil - en tant qu'utilisateur, je m'attendrais à ce que cela me déconnecte également de toutes les applications ( ou au moins me demander si j'aimerais le faire ?)

Nous pouvons inviter l'utilisateur à supprimer ses paires de clés, mais je ne m'attendrais jamais à ce qu'une déconnexion détruise mon jeton. Ce n'est pas le comportement normal ou attendu d'un système comme celui-ci et cela créerait probablement du chaos et des tonnes de demandes d'assistance.

Il n'offre aucune sécurité supplémentaire
Si, en tant qu'attaquant, j'ai déjà votre nom d'utilisateur et votre mot de passe, il n'y a rien que je ne puisse faire comme vous (en supposant qu'il n'y ait pas de 2FA en place).

Je suis catégoriquement en désaccord. Cette approche offre une sécurité supplémentaire pour accéder à vos ressources REST et si ce n'est pas évident, nous avons besoin de plus de documentation pour le rendre évident. Vous dites que si quelqu'un a déjà vos informations d'identification, vous êtes foutu, mais vous suggérez également que nous les utilisions pour donner accès à l'API REST. Si c'est ainsi que vous souhaitez accéder à REST, utilisez l'authentification de base. Parce que c'est exactement ce que nous implémenterions si nous utilisions user:pass pour créer des jetons.

Cela conduit au fait que, si, en tant que développeur d'applications novice, je souhaite faciliter la vie de mon utilisateur, je pourrais essayer quelque chose de déconseillé, comme utiliser un navigateur sans tête pour me connecter au compte de l'utilisateur, créer un jeton, lire les détails, puis les réintégrer dans mon application.

C'est là que nous voudrions créer un flux d'authentification qui permet de donner à une application la paire de clés via l'utilisation d'un rappel. Je crois que quelque chose comme ça a déjà été implémenté dans le plugin de mots de passe d'application.

Im donnez la paire de clés à l'application. Ensuite, les développeurs d'applications n'ont pas à créer des tonnes de mauvaises solutions et l'application ne stocke pas leurs user:pass .

Que pourrait-on faire à la place ?
La clé sert actuellement un objectif important - elle est utilisée pour permettre la révocation d'un jeton, même si les jetons ont potentiellement une très longue durée de vie. Cependant, nous n'avons pas nécessairement besoin d'une paire de clés pour le faire.

Exact, vous pouvez utiliser de nombreuses approches différentes.

S'inspirant de l'entrée session_tokens de WordPress dans usermeta - un ensemble stocké de clés de révocation spécifiques à JWT permettrait la même fonctionnalité, et il serait trivial d'implémenter la fonctionnalité "Déconnexion partout ailleurs" - il suffit de supprimer cette entrée de la table.

Cela ne remplacerait jamais la mise en œuvre actuelle à laquelle il devrait s'ajouter. En tant que développeur de logiciels d'entreprise, je n'utiliserais jamais cette méthode. Ainsi, même s'il s'agit d'une approche valide, elle n'a pas la capacité de s'attendre à ce qu'un jeton soit valide tant qu'il n'a pas expiré ou que le jeton n'est pas révoqué. Dans votre scénario, à la seconde où vous vous déconnectez, le jeton n'est pas valide. Ce serait pour l'OMI une déficience dans le flux d'authentification qui causerait d'innombrables problèmes avec la capacité de mes applications à accéder aux ressources, car elles sont désormais étroitement liées à l'utilisateur connecté.

Qu'en est-il du 2FA ?
Je me demande s'il serait possible d'autoriser un crochet que les plugins 2FA pourraient utiliser pour dire au client "veuillez réessayer, en fournissant un jeton 2FA" si un jeton était requis, mais non fourni. De plus, un autre hook (ou peut-être le même ?) pourrait être utilisé pour permettre au plugin 2FA de vérifier que le code fourni est correct ? Le système JWT ne ferait aucune hypothèse sur la façon dont 2FA est implémenté - cela serait laissé à un autre plugin - nous fournirions simplement les crochets pour rendre une telle chose possible.

Cela ajouterait à l'OMI une couche de complexité inutile qui pourrait potentiellement créer de nombreuses demandes d'assistance.

Merci d'avoir lu jusqu'ici – tout ce qui précède est à mon humble avis, mais j'espère que nous pourrons simplifier un peu ce processus pour les utilisateurs afin qu'il fonctionne très bien pour tout le monde.

Je suis sûr que j'ai raté au moins quelque chose, alors je suis heureux d'entendre les commentaires que les gens pourraient avoir à ce sujet !

Poste épique. Merci d'avoir pris le temps d'écrire tout cela. Vous y avez vraiment beaucoup réfléchi. Je veux dire que je n'essaie pas d'abattre quoi que ce soit. Juste que si nous allons autoriser la création de jetons avec une combinaison user:pass la façon dont nous le faisons doit être très très sécurisée et n'avoir aucun potentiel pour que les applications stockent vos identifiants de connexion.

Le point de séparer l'accès et l'authentification est intentionnel et ne doit pas être pris à la légère. Nous construisons l'authentification REST potentielle pour 1/3 d'Internet. Donc, jusqu'à ce que nous ayons une voie à suivre, j'ai supprimé la possibilité de créer des jetons avec les informations d'identification de l'utilisateur. Cela ne veut pas dire que nous ne pouvons pas le rajouter, juste qu'il a besoin de beaucoup de discussions avant de le faire.

Salut! D'après ce que je comprends, le principal problème de la conversation ici est la convivialité. En effet, le fait que les utilisateurs se rendent sur le site pour se connecter et créer les paires de clés sera une source de problèmes, voire de désagréments, pour certains utilisateurs.

Les développeurs essaieront probablement de trouver des moyens non sécurisés d'éviter cela de la même manière qu'aujourd'hui, ils suppriment les fonctionnalités qui nécessitent des mots de passe forts pour le bien de leurs utilisateurs.

Bien que je comprenne l'aspect sécurité de la décision, et que je sois d'accord avec. Mais nous devons trouver un moyen qui puisse fonctionner pour les deux.

Il semble que ce que vous avez dit ici @valendesigns pourrait être une solution possible :

Im donnez la paire de clés à l'application. Ensuite, les développeurs d'applications n'ont pas à créer des tonnes de mauvaises solutions et l'application ne stocke pas leur user:pass.

D'après ce que j'ai compris, nous conserverions essentiellement le flux actuel, ce qui est plus sécurisé car nous n'avons pas besoin de donner notre mot de passe à l'application au lieu de donner uniquement la paire de clés pour générer le jeton, mais cela pourrait être un obstacle pour certains .

Garder cet autre flux où nous n'aurions pas besoin de donner notre mot de passe à l'application étrangère. Au lieu de cela, demandez-leur de se connecter à WordPress et de générer la paire de clés.

J'aimerais plus d'informations sur cette partie :

Nous pouvons inviter l'utilisateur à supprimer ses paires de clés, mais je ne m'attendrais jamais à ce qu'une déconnexion détruise mon jeton. Ce n'est pas le comportement normal ou attendu d'un système comme celui-ci et cela créerait probablement du chaos et des tonnes de demandes d'assistance.

Il apparaît si je suis connecté sur site.com via le navigateur et l'application, si je clique sur "Déconnexion partout ailleurs" dans le navigateur, je serais également déconnecté de l'application, non ?! Je peux voir des applications où ce serait l'hypothèse. L'attente que vous seriez déconnecté partout.

La même chose devrait se produire lorsqu'un compte est supprimé.

Je suis d'accord avec ce qui a été dit à propos de l'UX de la paire de clés étant très peu convivial.

Il est donc très difficile de créer une application mobile native pouvant utiliser cette méthode Auth.

• J'avais créé il y a quelque temps un plugin personnalisé pour le (ancien) plugin OAuth1a qui affichait un code QR crypté (avec un mot de passe court et réglable) dans la page d'administration des applications (lorsque le nom de l'application et l'URL de rappel correspondaient à mon application), qui transmis les informations de l'application cliente à l'application mobile, pour permettre ensuite à l'utilisateur de s'authentifier.

Certes (jeu de mots), JWT est beaucoup plus facile que OAuth1a ;)

Puisqu'un utilisateur doit se connecter à Wordpress (espérons-le via https) en premier lieu, en utilisant un nom d'utilisateur et un mot de passe, je ne vois vraiment pas quel est le problème de sécurité d'avoir la paire nom d'utilisateur/mot de passe pouvant obtenir un jeton d'accès ? Tout est envoyé sur le même « fil » à la fin de la journée ? Sûrement?

L'application de la paire de clés d'application actuellement implémentée rend cette méthode d'authentification absolument impossible (dans le monde réel) pour qu'elle soit utilisée pour les applications mobiles.

Il n'y a tout simplement aucun moyen sensé d'obtenir une application mobile pour les saisir.

J'ai essayé les plugins OAuth1a, OAuth2 et maintenant deux JWT pour implémenter mes applications natives avec accès et tous échouent "prêts à l'emploi", sans piratage pour essayer de faire fonctionner les choses pour un utilisateur. Ce truc est censé devenir plus facile, sûrement?

Le plug -

Ce plugin "bientôt officiel" (j'espère !) échoue en raison du manque de convivialité pour les mobiles et en ignorant apparemment quel type d'applications peut être développé de manière réaliste pour cela. Et cela semble très myope.

Il y a une raison pour laquelle il y a un manque d'applications mobiles natives pour publier sur les sites wp.org. Et c'est ça.

S'il vous plaît, s'il vous plaît, pouvons-nous faire bouger les choses? (Je travaille sur une application native depuis des années maintenant, en attendant un moyen "correct" d'authentifier les utilisateurs, depuis l'introduction de l'API REST)

:)

Le flux de jetons UX est dingue et peu pratique pour une utilisation dans le monde réel, les utilisateurs devraient pouvoir se connecter avec un nom d'utilisateur et un mot de passe sur le système, demander une paire de clés API n'a aucun sens, vous n'utilisez pas d'abstraction ici, vous êtes supposé pour protéger les utilisateurs des détails techniques de l'utilisation de votre application, comment ressentirez-vous que pour vous connecter à Facebook sur votre téléphone, vous devez vous connecter à un portail d'administration sur Facebook et créer une paire de clés API, puis utiliser la paire de clés API pour se connecter, nous ne développons pas pour les développeurs, nous développons pour le client qui ne sait pas en quoi consiste l'aspect technique de votre service, désinstallant tout de suite. Je ne vois vraiment pas en quoi ce plugin est utile pour l'authentification.

Ce problème avec la connexion utilisateur > le flux de jetons retarde sérieusement le développement de TELLEMENT d'applications qui pourraient utiliser JWT.

Les mois et les mois continuent et on ne s'en occupe tout simplement pas.

Comme je l'ai dit ci-dessus, le fait que les utilisateurs utilisent une paire nom d'utilisateur/mot de passe pour se connecter réellement à l'administrateur fait que tout argument pour ne pas utiliser de paires nom d'utilisateur/mot de passe pour obtenir un jeton semble quelque peu invalide ? Sûrement?

Juste pour mettre à jour ce fil – il semble que ce projet soit remplacé par un autre pour implémenter un flux OAuth complet dans le noyau WP. Il devrait aborder les inconvénients des approches discutées ici tout en conservant tous les points forts.

Si vous souhaitez vous impliquer, n'hésitez pas à vous lancer dans #core-restapi sur Slack .