Für ein neues node.js-Projekt, an dem ich arbeite, denke ich darüber nach, von einem Cookie-basierten Sitzungsansatz zu wechseln (damit meine ich das Speichern einer ID in einem Schlüsselwertspeicher, der Benutzersitzungen im Browser eines Benutzers enthält). zu einem tokenbasierten Sitzungsansatz (kein Schlüsselwertspeicher) unter Verwendung von JSON-Web-Tokens (jwt).
Das Projekt ist ein Spiel, das socket.io verwendet. Eine tokenbasierte Sitzung wäre in einem solchen Szenario nützlich, in dem mehrere Kommunikationskanäle in einer einzigen Sitzung vorhanden sind (web und socket.io).
Wie würde man mit dem jwt-Ansatz eine Token- / Sitzungsinvalidierung vom Server bereitstellen?
Ich wollte auch verstehen, auf welche häufigen (oder ungewöhnlichen) Fallstricke / Angriffe ich bei dieser Art von Paradigma achten sollte. Zum Beispiel, wenn dieses Paradigma für dieselben / unterschiedliche Arten von Angriffen anfällig ist wie der auf Session Store / Cookies basierende Ansatz.
Sagen wir also, ich habe folgendes (angepasst von diesem und jenem ):
Session Store Login:
app.get('/login', function(request, response) {
var user = {username: request.body.username, password: request.body.password };
// Validate somehow
validate(user, function(isValid, profile) {
// Create session token
var token= createSessionToken();
// Add to a key-value database
KeyValueStore.add({token: {userid: profile.id, expiresInMinutes: 60}});
// The client should save this session token in a cookie
response.json({sessionToken: token});
});
}Token-basiertes Login:
var jwt = require('jsonwebtoken');
app.get('/login', function(request, response) {
var user = {username: request.body.username, password: request.body.password };
// Validate somehow
validate(user, function(isValid, profile) {
var token = jwt.sign(profile, 'My Super Secret', {expiresInMinutes: 60});
response.json({token: token});
});
}- -
Eine Abmeldung (oder Ungültigmachung) für den Session Store-Ansatz würde eine Aktualisierung der KeyValueStore-Datenbank mit dem angegebenen Token erfordern.
Es scheint, als würde ein solcher Mechanismus im tokenbasierten Ansatz nicht existieren, da das Token selbst die Informationen enthalten würde, die normalerweise im Schlüsselwertspeicher vorhanden wären.
isRevokedOption ansehen oder versuchen, dieselbe Funktionalität zu replizieren. github.com/auth0/express-jwt#revoked-tokens