Feathers: Authentifizierung als nächstes

Reisepass verwerfen

Diese Diskussion begann in #844 und fasst in https://github.com/feathersjs/feathers/issues/844#issuecomment -390123148 ​​die Punkte zusammen, warum dies geschieht. Kurz gesagt, es hat sich in PassportJS nicht viel entwickelt, insbesondere in Bezug auf die Unterstützung anderer Frameworks als Express und die meisten anderen HTTP-Frameworks wie Koa oder Hapi sind dazu übergegangen, flexiblere und minimalistische Authentifizierungsbibliotheken zu verwenden (wie https://github.com/simov/grant .). für oAuth). Es stellte sich auch heraus, dass es nur vier Arten von Strategien gibt, die wirklich benötigt werden:

• Lokal (Benutzername/Passwort)
• JWT
• oAuth (+ oAuth-Zugriffstoken)
• API-Schlüssel

Ohne Passport umgehen zu müssen, kann Feathers problemlos auf jeder HTTP-Bibliothek und jedem anderen Transportmechanismus (wie MQTT- oder sogar P2P-Verbindungen) mit einer klaren Trennung der Bedenken sitzen und einen Authentifizierungsmechanismus bereitstellen, der viel einfacher zu verstehen und anzupassen ist.

Verwenden von params.authentication

Auf der Seite von Feathers ist das Festlegen von params.authentication in einem Serviceaufruf die _einzige_ Möglichkeit, Authentifizierungsinformationen bereitzustellen. params.authentication enthält die Informationen, die zum Authentifizieren des Serviceaufrufs erforderlich sind, und haben das Format { strategy: 'local', email: 'email', password: 'password' } , das bereits verwendet wird:

// Call `find` with a given JWT
app.service('messages').find({
  authentication: {
    strategy: 'jwt',
    accessToken: 'someJWT'
  }
});

Der Aufrufer (wie ein REST- oder Websocket-Transport, ein Hook oder ein Unit-Test) ist dafür verantwortlich, params.authentication . Dies bedeutet, dass es keine Verwirrung mehr gibt, ob der authenticate Hook für interne Anrufe ausgeführt wird oder nicht oder woher die Authentifizierungsinformationen tatsächlich stammen.

Der authenticate Haken

Der Hook authenticate wird weiterhin existieren. Es braucht eine Liste von Strategienamen und wird entweder

• Fahren Sie mit der ersten Strategie, die keinen Fehler verursacht hat, mit dem nächsten Hook fort und fügen Sie ihren Rückgabewert (siehe unten) in params

• Oder werfen Sie den Fehler der ersten fehlgeschlagenen Strategie, wenn alle Strategien fehlgeschlagen sind

  Wenn params.authentication einen strategy Namen enthält, wird nur diese Strategie aufgerufen. Andernfalls werden alle Strategien aufgerufen. Wenn params.authentication nicht gesetzt ist, wird der Hook

• Fehler bei externen Anrufen auslösen

• Bei internen Anrufen wie gewohnt fortfahren (zB params.user manueller Einstellung von

app.service('messages').hooks({
  before: authenticate('jwt', 'local', 'anonymous')
});

Authentifizierungsstrategien

Eine grundlegende Authentifizierungsstrategie ist ein Objekt mit einer authenticate Methode, das die Daten von params.authentication abruft und ein Erfolgsobjekt zurückgibt oder einen Fehler auslöst, wenn es nicht erfolgreich war:

const { Forbidden } = require('@feathersjs/errors');

const daveStrategy = {
  async authenticate (authParams) {
    const { username, password } = authParams;

    if (username === 'david' && password === 'secret') {
      return {
        user: {
          name: 'Dave',
          admin: true
        }
      };
    }

    throw new Forbidden('Not super Dave');
  }
};

app.authentication.registerStrategy('superdave', daveStrategy);

Im authenticate Hook wird das zurückgegebene Objekt mit dem Serviceaufruf params so dass dieses Beispiel params.user .

Strategien erweitern

Authentifizierungsstrategien können intern zusätzliche Methoden enthalten und aufrufen. Feathers-Strategien werden als Klassen implementiert, die durch Erweiterung angepasst werden können (dies ersetzt die Verifiers und kombiniert im Wesentlichen die Strategie und den Verifier in einer einzigen Klasse):

class LocalStrategy {
  constructor(app);
  async findUser(authParams);
  async comparePassword(user, password);
  async authenticate (authParams);
}

class MyLocalStrategy extends LocalStrategy {
  async findUser(authParams);
}

app.authentication.registerStrategy('local', new MyLocalStrategy(app));

HTTP-Parsing

Eine Strategie kann auch eine parse Methode bereitstellen, die eine grundlegende Node-HTTP-Anfrage und -Antwort erhält und den Wert für params.authentication (oder null ) zurückgeben sollte:

const daveStrategy = {
  async authenticate (authParams) {
    throw new Forbidden('Not super Dave');
  }

  async parse (req, res) {
    const apiKey = req.headers['x-super-dave'];

    if (apiKey) {
      return {
        strategy: 'superdave',
        apiKey
      }
    }

    return null;
  }
};

HTTP-Bibliotheken können dann entscheiden, ob und wie sie diese Methoden verwenden, um params.authentication festzulegen oder ihre eigene Middleware zu authentifizieren.

app.authentifizieren

app.authenticate(authParams, [ strategies ]) führt die angegebenen Strategien mit den angegebenen Authentifizierungsparametern aus:

// Will return the user for a JWT (on the server)
const { user } = app.authenticate({ accessToken }, 'jwt');

Das Festlegen von params.authentication in einem Serviceaufruf ist die _einzige_ Möglichkeit, Authentifizierungsinformationen bereitzustellen.

Könnten Sie die Entwurfspunkte erläutern, warum es notwendig war, accessToken bei jedem service() Aufruf bereitzustellen?

Dies gilt nur für den Server und geschieht implizit bereits durch params.provider und params.headers (bei Websockets sind dies nur Fake-Header), die nach der Konfiguration der Authentifizierung für jeden Serviceaufruf gesetzt werden. Dies brach die Trennung von Feathers zwischen Transportprotokoll-unabhängigen Hooks und Diensten und dem eigentlichen Transportmechanismus (wie HTTP mit Express oder Socket.io) und machte es wirklich verwirrend, wenn zB ein authenticate('jwt') Hook tatsächlich läuft und wofür er verwendet wird seine Authentifizierungsinformationen.

Usability-technisch wird sich bei externen oder internen Aufrufen nichts wirklich ändern, aber wenn Sie jetzt den authenticate Hook explizit auf dem Server auslösen möchten, können Sie immer params.authentication . Dies ist besonders wichtig für neue Framework-Plugins außer Express (zB Koa, HTTP2 oder eine Messaging-Warteschlange), die jetzt eine standardisierte Möglichkeit haben, ihre Authentifizierungsinformationen an den Authentifizierungsmechanismus von Feather weiterzugeben.

Der Authentifizierungsclient stellt weiterhin authentifizierte Anfragen, nachdem er sich durch Aufrufen von app.authenticate() angemeldet hat.

Danke fürs klarstellen. Ich freue mich sehr darauf, mit v3 zu testen, insbesondere mit socket.io React Native-Clients.

Werde auf jeden Fall die Infos zu Prereleases hier einstellen. Einfach den Authentifizierungsclient einpacken, der authentifizierte Websockets viel zuverlässiger handhaben sollte. Sobald dies erledigt ist, wäre es großartig, Hilfe beim Testen des neuen Kerns + der lokalen und der jwt-Authentifizierung zu haben. oAuth sollte danach bald folgen.

wann kommt Version 3 raus?

Irgendeine Antwort auf meine Frage?

Den aktuellen Fortschritt seht ihr im Master-Branch und ich werde einen Blog-Beitrag veröffentlichen, wenn Beta-Tester es ausprobieren können. Der Status ist:

| Modul | Code | Dokumente | CLI
| --- |:---:|:---:|---:|
| @feathersjs/authentication | | 100% | |
| @feathersjs/authentication-local | | 80% | |
| @featherjs/authentication-oauth | | 90%| |
| @feathersjs/authentication-client | | 80%| |

Hallo, das ist großartig!

Zukünftige Flexibilität ist cool, aber ich habe in meinem FeathersJS-Projekt noch kein Vertrauen in auth und ich durchlaufe einen verwirrenden Prozess, um das zu schaffen.

Mit einer vollständigen, getesteten und sicheren Authentifizierungsimplementierung kann ich zuversichtlich zu den Funktionen übergehen. Einer der besten Gründe für den Einsatz MeteorJS war es ausgezeichnet ist Konten Integration des ganzen Weg an den Client.

Wenn man sich die FeatherJS-Probleme ansieht, geht es bei vielen um die Authentifizierung, daher freue ich mich darauf, dass diese Arbeit veröffentlicht wird!

Wo ist heute die beste Dokumentation (oder Referenzimplementierung) für ein komplettes sicheres Authentifizierungssystem (lokale Authentifizierung, Zugriffskontrolle, E-Mails usw.) in FeathersJS?

Das habe ich bisher - gibt es etwas besseres?

2018/02 - Einrichten der E-Mail-Verifizierung in FeathersJS (Rehash des Artikels von 2017)
2018/02 - Repo aus Artikel oben
2017/01 - So richten Sie die E-Mail-Verifizierung in FeathersJS ein (kaputt)
2018/06 - Vue-Authentifizierung mit Feathersjs

Danke im Voraus!

Alle damit verbundenen Probleme wurden nun geschlossen und die Vorabversion für Feathers v4 mit allen vorgeschlagenen Änderungen ist zum Testen verfügbar. Weitere Informationen finden Sie im Migrationshandbuch .