J’ai mis en place un flux de connexion qui authentifie une application front-end (écrite en Vue.js) pour récupérer la user_api_key d’un utilisateur Discourse, en suivant les directives rédigées par @samici.
L’authentification fonctionne, mais ma préoccupation porte sur le stockage sécurisé de la clé privée. Pour le moment, la clé privée est stockée localement dans le fichier .env et utilisée pour le chiffrement/déchiffrement de la charge utile. Est-ce une méthode sécurisée pour chiffrer la charge utile ? Si non, quelles sont les alternatives pour une application JavaScript front-end ?
Comme dans une application Electron/Tauri ? Je ne sais pas du tout ce que vous choisiriez. Je suppose qu’ils disposent d’un mécanisme de stockage sécurisé. Peut-être, si vous avez de la chance, pourrez-vous utiliser le trousseau sur Mac et quelque chose de similaire sur Windows.
C’est une application web hébergée sur un serveur. La préoccupation est que la charge utile pourrait être interceptée si la clé privée est exposée. Je suis conscient que c’est une préoccupation plus générale avec le chiffrement JavaScript, mais je pose la question au cas où il existerait une pratique plus sécurisée pour authentifier une application web depuis Discourse.
Le système de clé API utilisateur n’est pas conçu pour ce cas d’usage. Si vous passez par la procédure de génération d’une clé privée pour ensuite la stocker sur le serveur au nom de l’utilisateur, à quoi bon toute cette démarche ? Il suffit de générer les clés côté serveur.
Il m’est très difficile de vous donner des conseils sans comprendre pleinement le problème réel dans ses moindres détails. Pourquoi ne pas simplement fournir des points de terminaison proxy dans votre application web et gérer toute l’authentification dans votre application ?
Après avoir discuté avec mon collègue @owengot, voici une description plus détaillée du problème.
Il existe une application web basée sur Vue.js qui ne dispose pas de son propre composant côté serveur actif. Il s’agit plutôt d’une application web autonome qui utilise l’API Discourse, de sorte que, d’une certaine manière, Discourse joue le rôle du serveur. Les cas d’usage incluent des sondages ou formulaires autonomes, où le contenu est publié dans des sujets Discourse sous le compte de l’utilisateur. Pouvoir créer un tel logiciel sans composants personnalisés côté serveur semblait être une bonne architecture pour ces cas d’usage ; idéalement, nous voudrions donc éviter de faire quoi que ce soit « côté serveur ».
Maintenant, l’obtention d’une clé API utilisateur fonctionne comme prévu, mais @owengot a découvert que l’étape de génération d’une clé privée en JavaScript prend beaucoup de temps (jusqu’à 10 secondes, c’est simplement inefficace en JavaScript …). Ensuite, il a découvert l’astuce consistant à utiliser la même clé privée pour plusieurs utilisateurs, il l’a donc stockée dans un fichier sur l’hébergeur web qui sert également les autres fichiers statiques de l’application web (JS, CSS, etc.). Cela rend le processus rapide … mais cette clé privée est maintenant (1) partagée et (2) stockée en clair, avec une URL accessible publiquement. Cela semble, euh, effrayant
J’ai donc dit que nous devions demander à l’équipe Discourse quelles sont les implications de sécurité de cette astuce. Je vois deux alternatives de base :
Si cette clé privée n’est « que » utilisée pour le chiffrement des charges utiles, nous pourrions nous en accommoder, car la communication est également chiffrée via SSL / HTTPS.
Mais si connaître cette clé privée permet de calculer la clé API utilisateur résultante, utilisée ensuite pour publier sous le compte Discourse de quelqu’un, cela rendrait bien sûr cette astuce inacceptable.
Je suis aussi curieux à ce sujet, car j’ai commencé à utiliser le logiciel développé par @owengot. D’après ce que dit @tanius, penses-tu que ce soit une méthode sûre, @sam ?
