Understanding authentication flow mit refresh und access tokens auf nodejs app

Question

Ich weiß, es gibt bereits viele Beiträge über Oauth, Oauth2, JWT, etc .. Ich habe viele gelesen und ich mehr verwirrt als je zuvor, so bin ich auf der Suche nach etwas Klärung. Ich werde meine Meinung zu dem Thema vorschlagen, und ich hoffe, dass mir jemand sagen kann, ob meine Umsetzung sicher genug ist oder was ich falsch mache und wie ich es verbessern kann.

Ich baue einen API-Rest-Server, um meine Ressourcen an meine Benutzer zu liefern. Nehmen wir an, es handelt sich um eine Bank-App, mit der Nutzer Geld einzahlen, abheben und transferieren können.

Ich verwende nodejs, hapijs, jsonwebtokens und bcrypt für meinen Server. Ich möchte zwei Token Authentifizierungsablauf (Oauth2) implementieren.

Dies ist die Art, wie ich es tue:

1. Benutzer bei dem Authentifizierungsserver, indem er einige Anmeldeinformationen (Benutzername und Passwort) zu geben.

2. Der Server überprüft die Anmeldeinformationen des Benutzers, sofern diese gültig sind, gewährt er dem Benutzer Zugriff und gibt ein Aktualisierungstoken und ein Zugriffstoken zurück.

3. Diese Token werden im lokalen Speicher des Browsers oder mobilen Geräts gespeichert.

4. Die access token:

   • als jsonwebtoken unterzeichnet.
   • enthält ausgegebenes Datum, Ablaufdatum (5 min), Benutzerdaten (ID, Benutzername).

5. Die refresh token:

   • als jsonwebtoken und verschlüsselt mit bcrypt unterzeichnet.
   • enthält eine eindeutige Kennung
   • kann in der Datenbank ein Ablaufdatum
   • wird gespeichert enthalten.

6. Solange die access token gültig ist, das heißt, es ist nicht abgelaufen ist, und enthält gültige Benutzerdaten, die Ressource-Server dient dem Benutzer die angeforderten Ressourcen.

7. Wenn die access token nicht mehr gültig ist, fordert der Auth-Server das Client ein refresh token bereitzustellen, um einen neuen access token

   • den Server die refresh token vom Anwender erhält zu erteilen, entschlüsselt sie, es vergleicht zu dem in der Datenbank, überprüft, ob es widerrufen wurde, und überprüft seine eindeutige Kennung. Wenn die refresh token alle Tests besteht, gibt der Server einen neuen access token an den Client aus.
   • Wenn die refresh token einen Test fehlschlägt, fordert der Server den Benutzer zur erneuten Authentifizierung.

Hinweise: Ich versuche, die Verwendung von Cookies zu vermeiden.

Fragen:

• Wenn der Benutzer in der Lage, eine access token zu stehlen, ich denke, es auch die refresh token stehlen kann. Also, wie kann ich die refresh token sicherer machen?
• Ist meine Perspektive des Oauth2-Flusses korrekt?
• Was kann ich verbessern?
• Fehle ich etwas?

Answer 1

Der Grund, warum OAuth2 für viele Leute so verwirrend ist, ist, dass es verschiedene Authentifizierungsabläufe verwendet, je nachdem, welche Art von Client verwendet wird.

OAuth2 unterscheidet zwei client type, vertraulich oder öffentlich. Darüber hinaus gibt es 2 Zuweisungsflüsse, die auf Umleitung basieren (Auth-Code und implizit), die mit einem Browser oder einer Browsersteuerung verwendet werden sollen.

Die anderen beiden Flüsse (Ressourceneignerkennwort und Clientanmeldeinformationen) sind für Nicht-Browser-Apps (CLI, Hintergrunddienste, vertrauenswürdige mobile Clients) vorgesehen.

Ich habe die verschiedenen Ströme und wann sie in this answer here genauer zu beschreiben.