SPA bewährte Methoden für die Authentifizierung und Sitzungsverwaltung

Question

Beim Aufbau von SPA-Stil-Anwendungen mit Frameworks wie Angular, Ember, React usw., was sind einige bewährte Methoden für die Authentifizierung und Sitzungsverwaltung? Ich kann mir ein paar Möglichkeiten vorstellen, wie man das Problem angehen könnte.

1. Behandeln Sie es nicht anders als die Authentifizierung mit einer regulären Webanwendung, vorausgesetzt, die API und das UI haben die gleiche Ursprungsdomäne.

   Dies würde wahrscheinlich beinhalten, dass es ein Session-Cookie, serverseitige Sitzungsspeicherung und wahrscheinlich einen Session-API-Endpunkt gibt, den das authentifizierte Web-UI aufrufen kann, um aktuelle Benutzerinformationen abzurufen, um bei der Personalisierung oder möglicherweise sogar bei der Bestimmung von Rollen/Fähigkeiten auf der Clientseite zu helfen. Der Server würde natürlich weiterhin Regeln durchsetzen, die den Zugriff auf Daten schützen, das UI würde diese Informationen jedoch verwenden, um das Erlebnis anzupassen.

2. Behandeln Sie es wie einen beliebigen Drittanbieter-Client, der eine öffentliche API verwendet, und authentifizieren Sie sich mit einem Token-System ähnlich wie OAuth. Dieses Token-Mechanismus würde vom Client-UI verwendet, um jede Anfrage, die an die Server-API gesendet wird, zu authentifizieren.

Ich bin hier nicht wirklich ein Experte, aber #1 scheint für die allermeisten Fälle völlig ausreichend zu sein, aber ich würde wirklich gerne einige erfahrene Meinungen hören.

Answer 1

Sie können die Sicherheit im Authentifizierungsprozess erhöhen, indem Sie JWT (JSON Web Tokens) und SSL/HTTPS verwenden.

Die Basic Auth / Session-ID kann gestohlen werden durch:

• MITM-Angriff (Man-In-The-Middle) - ohne SSL/HTTPS
• Ein Eindringling gewinnt Zugriff auf den Computer eines Benutzers
• XSS

Durch die Verwendung von JWT werden die Authentifizierungsdetails des Benutzers verschlüsselt und im Client gespeichert, und bei jeder Anfrage an die API gesendet, wo der Server/API das Token validiert. Es kann nicht entschlüsselt/lesen werden ohne den privaten Schlüssel (den der Server/API geheim hält) Lesen Sie das Update.

Der neue (sicherere) Ablauf wäre:

Einloggen

• Benutzer meldet sich an und sendet Anmeldeinformationen an die API (über SSL/HTTPS)
• Die API empfängt die Anmeldeinformationen
• Wenn gültig:
• Neue Sitzung in der Datenbank registrieren Lesen Sie das Update
• Benutzer-ID, Sitzungs-ID, IP-Adresse, Zeitstempel usw. mit einem privaten Schlüssel in einem JWT verschlüsseln
• API sendet das JWT-Token zurück an den Client (über SSL/HTTPS)
• Der Client empfängt das JWT-Token und speichert es in localStorage/Cookie

Jede Anfrage an die API

• Benutzer sendet eine HTTP-Anfrage an die API (über SSL/HTTPS) mit dem gespeicherten JWT-Token im HTTP-Header
• Die API liest den HTTP-Header und entschlüsselt das JWT-Token mit seinem privaten Schlüssel
• Die API validiert das JWT-Token, gleicht die IP-Adresse der HTTP-Anfrage mit der im JWT-Token ab und überprüft, ob die Sitzung abgelaufen ist
• Wenn gültig:
• Antwort mit angefordertem Inhalt zurückgeben
• Wenn ungültig:
• Ausnahme werfen (403 / 401)
• Einbruch im System kennzeichnen
• Eine Warn-E-Mail an den Benutzer senden.

Aktualisiert am 30.07.15:

JWT-Payload/Claims können tatsächlich ohne den privaten Schlüssel (Geheimnis) gelesen werden und es ist nicht sicher, es in localStorage zu speichern. Es tut mir leid über diese falschen Aussagen. Sie scheinen jedoch an einem JWE-Standard (JSON Web Encryption) zu arbeiten.

Ich habe dies umgesetzt, indem ich Ansprüche (Benutzer-ID, exp) in einem JWT gespeichert habe, es mit einem privaten Schlüssel (Geheimnis) signiert habe, den nur die API/backend kennt, und es als sicheres HttpOnly-Cookie auf dem Client gespeichert habe. Auf diese Weise kann es nicht über XSS gelesen werden und kann nicht manipuliert werden, da das JWT die Signaturprüfung fehlschlägt. Auch durch Verwendung eines sicheren HttpOnly-Cookies stellen Sie sicher, dass das Cookie nur über HTTP-Anfragen gesendet wird (nicht zugänglich für Skript) und nur über eine sichere Verbindung gesendet wird (HTTPS).

Aktualisiert am 17.07.16:

JWTs sind von Natur aus zustandslos. Das bedeutet, sie invalidieren/verfallen von selbst. Indem Sie die Session-ID in den Ansprüchen des Tokens hinzufügen, machen Sie es zustandsbehaftet, weil dessen Gültigkeit nicht mehr nur von der Signaturprüfung und dem Ablaufdatum abhängt, sondern auch vom Sitzungszustand auf dem Server. Der Vorteil ist jedoch, dass Sie Tokens/Sitzungen leicht ungültig machen können, was mit zustandslosen JWTs bisher nicht möglich war.

Answer 2

Ich würde mich für das Zweite entscheiden, das Token-System.

Hast du von ember-auth oder ember-simple-auth gehört? Beide verwenden das Token-basierte System, wie es in ember-simple-auth heißt:

Ein leichtgewichtige und unauffällige Bibliothek zur Implementierung von tokenbasierten Authentifizierung in Ember.js-Anwendungen. http://ember-simple-auth.simplabs.com

Sie verfügen über Sitzungsverwaltung und sind auch einfach in bestehende Projekte einzubinden.

Es gibt auch eine Beispielversion von ember-simple-auth für Ember App Kit: Funktionsfähiges Beispiel von ember-app-kit mit Verwendung von ember-simple-auth für OAuth2-Authentifizierung.