Ich habe einen Login-Flow erstellt, der eine Frontend-Anwendung (geschrieben in Vue.js) authentifiziert, um den user_api_key eines Discourse-Benutzers abzurufen, und dabei die von @samhier beschriebenen Richtlinien befolgt.
Die Authentifizierung funktioniert, aber meine Sorge gilt der sicheren Speicherung des privaten Schlüssels. Derzeit wird der private Schlüssel lokal in der .env-Datei gespeichert und zur Verschlüsselung/Entschlüsselung der Nutzdaten verwendet. Ist dies eine sichere Methode zur Verschlüsselung der Nutzdaten? Falls nein – welche Alternativen gibt es für eine Frontend-JavaScript-Anwendung?
Wie in einer Electron-/Tauri-App? Ich habe keine Ahnung, was Sie wählen würden. Ich gehe davon aus, dass sie einen Mechanismus für die sichere Speicherung haben. Vielleicht können Sie, wenn Sie Glück haben, den Keychain auf dem Mac und etwas Ähnliches unter Windows verwenden.
Es handelt sich um eine Webanwendung, die auf einem Server gehostet wird. Die Sorge besteht darin, dass die Nutzdaten möglicherweise abgefangen werden könnten, wenn der private Schlüssel kompromittiert wird. Mir ist bewusst, dass dies ein allgemeineres Problem bei der Verschlüsselung mit JavaScript ist, aber ich frage trotzdem, ob es für die Authentifizierung einer Webanwendung von Discourse aus eine sicherere Praxis gibt.
Das API-Key-System für Benutzer ist nicht für diesen Anwendungsfall konzipiert. Wenn Sie den Aufwand betreiben, einen privaten Schlüssel zu generieren und diesen dann im Namen des Benutzers auf dem Server zu speichern, wozu dann all dieser Aufwand? Generieren Sie die Schlüssel einfach serverseitig.
Es ist für mich sehr schwierig, eine Anleitung zu geben, ohne das eigentliche Problem im Detail vollständig zu verstehen. Warum stellen Sie nicht einfach Proxy-Endpunkte in Ihrer Webanwendung bereit und übernehmen die gesamte Authentifizierung in Ihrer App?
Nach einem Gespräch mit meinem Kollegen @owengot folgt hier eine detailliertere Beschreibung des Problems.
Es gibt eine auf Vue.js basierende Webanwendung, die keine eigene serverseitige Komponente besitzt. Es handelt sich vielmehr um eine eigenständige Webanwendung, die die Discourse-API nutzt – in gewisser Weise ist Discourse also der Server. Anwendungsfälle sind beispielsweise eigenständige Umfragen oder Formulare, bei denen der Inhalt unter dem Benutzerkonto in Discourse-Themen gepostet wird. Die Möglichkeit, eine solche Software ohne benutzerdefinierte serverseitige Komponenten zu erstellen, erschien als eine attraktive Architektur für diese Zwecke. Idealerweise möchten wir daher vermeiden, irgendetwas „serverseitig
Ich bin auch neugierig darauf, da ich die von @owengot entwickelte Software zu nutzen begonnen habe. Basierend auf dem, was @tanius gesagt hat, denkst du, dass dies eine sichere Vorgehensweise ist, @sam?