Authentifizierung über Token


8

Ich bin relativ neu in jwt.io und der Authentifizierung und verwende JWT.io auf folgende Weise.

Serverseite

Sobald sich der Benutzer anmeldet, generiere ich ein Token mit userideingebettetem Inhalt und gebe es an den Benutzer im Nachrichtentext zurück

Client Side Browser / JS Ich speichere das Token in localStorage und übergebe das Token für jede nachfolgende Anforderung in den Headern.

Authorization: Basic someEncryptedValue

Ich habe auch verwendet

X-Auth-Token: someEncryptedValue

Könnte ich dies in einem Cookie verwenden?

Dann überprüfe ich auf der Serverseite das Token anhand des Geheimnisses, überprüfe den Ablauf, hole die ID aus dem Token heraus und bearbeite dann die Anforderung.

Ist in diesem Workflow alles korrekt?


Gibt es einen Grund, einem Standard wie OAuth2 nicht zu folgen? Übrigens: Sie sollten das Token nicht als grundlegenden Auth-Header übergeben, sondern Authorization: Bearer
Arne Burmeister am

Ja, Träger ist der richtige, OAuth2 ist, dass ich davon ausgehe, Benutzer über Dritte wie Google, Facebook usw. zu authentifizieren. Während dies mein eigenes Authentifizierungsschema gegen das Benutzerpasswort ist,
klären

1
Die Authentifizierung durch Dritte ist nur eine Funktion von OAuth. Sie funktioniert perfekt mit JWT und einem eigenen Authentifizierungsserver
Arne Burmeister,

ok, bitte
klären

2
OAuth ist nur erforderlich, wenn Sie Anwendungen benötigen, die Informationen zwischen ihnen austauschen. Für eine so grundlegende Funktion wie die Authentifizierung reicht Jwt aus.
Laiv

Antworten:


1

Ihr Workflow ist korrekt (vorausgesetzt, Sie verwenden HTTPS), und ja, Sie können Ihr Token einfach in einem Cookie speichern, anstatt es im Autorisierungsheader zu übergeben.

Ich empfehle nicht, OAuth2 zu verwenden. Die ordnungsgemäße Implementierung selbst des einfachsten Ablaufs würde Ihren Anmeldevorgang erheblich komplexer machen, und es scheint mir, dass Sie ihn nicht benötigen, da Ihre "serverseitigen" Teile alle in derselben Domäne leben.

Wenn ich es wäre, würde ich Cookies verwenden. Das Festhalten an gut verstandenen Schemata lässt weniger Verwirrung stiften und bedeutet, dass der Browser sich um das Senden und Aktualisieren Ihres Cookies kümmert (z. B. überlegen Sie, wie Sie mit Sitzungen mit einer Leerlaufzeit umgehen können).


1
Haben Sie die Unterschiede zwischen einem XSS- und einem CSRF-Angriff berücksichtigt? Ich schlage respektvoll vor, dass die Verwendung von Cookies allein zu einer CSRF-Sicherheitsanfälligkeit führen kann, die leichter auszunutzen ist als ein Angriff im XSS-Stil, während eine tokenbasierte Authentifizierung, obwohl sie immer noch anfällig ist, schwerer auszunutzen ist. In beiden Fällen müssen zum Schutz vor beiden Arten von Angriffen sowohl Cookies als auch Header-Token in der Anforderung vorhanden sein, um den Benutzer als authentifiziert und autorisiert zu betrachten.
RibaldEddie

@RibaldEddie Nein, hatte ich nicht - ich glaube, ich nahm an, dass ein anderer Mechanismus verwendet werden würde, um CSRF zu verhindern. Gibt es eine Chance, dass Sie näher darauf eingehen könnten? Wie ist die tokenbasierte Authentifizierung immer noch anfällig? Und wie schützt die Verwendung beider Methoden vor CSRF?
Justin

Das verschlüsselte Token-Muster ist eine Lösung. So ist das Double-Submit-Cookie. Beide benötigen einen anderen Wert, der mit der Anforderung gesendet wird, wenn Cookies zum Übergeben der Anmeldeinformationen verwendet werden.
RibaldEddie

0

Eine gute Lektüre. Es geht darum, Token im lokalen Speicher zu speichern und dann in der http-Anfrage über Javascript zurückzusenden.

: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage


6
Bitte verlinken Sie nicht nur auf externe Websites, um das Verrotten von Links zu verhindern. Wenn der Artikel wertvolle Informationen enthält, geben Sie eine Zusammenfassung des Artikels an und veröffentlichen Sie ihn hier.
Andy

1
Es gibt viele wertvolle Informationen, eine Zusammenfassung der Höhepunkte wäre schön (wie die JWT-Signatur nutzen, Cookies verwenden und einige andere Schritte).
Berin Loritsch

0

Alle Browser unterstützen jetzt Digest Auth, das auch über HTTP sicher ist. Abhängig von Ihren genauen Anforderungen kann dies ausreichend sein.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.