Session, JWT, SSO, OAuth 2.0: Vorteile, Nachteile und Anwendungsfälle

Im Frontend-Projektentwicklung gibt es vier Hauptmethoden für die Benutzerauthentifizierung: Session, JWT, SSO und OAuth 2.0.

Was sind also die Vor- und Nachteile dieser vier Methoden? Vergleichen wir sie heute!

Klassische sitzungsbasierte Authentifizierung

Was ist sitzungsbasierte Authentifizierung?

Die sitzungsbasierte Authentifizierung ist eine häufig verwendete Methode zur Benutzerauthentifizierung in Frontend- und Backend-Systemen.

Sie basiert hauptsächlich auf dem Server, um Benutzersitzungen zu erstellen und zu verwalten.

Wie Session funktioniert

Der Sitzungsauthentifizierungsprozess besteht aus sechs Schritten:

1. Benutzeranmeldung: Der Benutzer gibt seine Anmeldeinformationen (z. B. Benutzername und Passwort) auf der Anmeldeseite ein. Diese Anmeldeinformationen werden vom Frontend zur Validierung an den Backend-Server gesendet.
2. Sitzung erstellen: Nach der Validierung der Anmeldeinformationen erstellt der Backend-Server eine Sitzung, die normalerweise eine eindeutige Sitzungs-ID enthält, die auf dem Server gespeichert wird.
3. Sitzungs-ID zurückgeben: Der Server sendet die Sitzungs-ID zurück an das Frontend, normalerweise über ein Cookie. Dieses Cookie wird im Browser des Benutzers gespeichert und bei nachfolgenden Anfragen automatisch mitgesendet.
4. Sitzungs-ID speichern: Der Browser speichert das Cookie und fügt es automatisch in jede an den Server gesendete Anfrage ein. Dies ermöglicht es dem Server, die Sitzung des Benutzers zu erkennen und ihn zu authentifizieren.
5. Sitzungsvalidierung: Der Server sucht die Sitzungs-ID und überprüft die zugehörigen Sitzungsinformationen, um die Identität des Benutzers zu bestimmen. Er kann die Sitzungsdaten auch für Berechtigungsprüfungen und Zugriffskontrolle verwenden.
6. Sitzungsablauf und -verwaltung: Der Server kann Sitzungsablaufzeiten festlegen und in regelmäßigen Abständen abgelaufene Sitzungen löschen. Wenn sich ein Benutzer abmeldet oder die Sitzung abläuft, löscht oder ungültig macht der Server die Sitzung.

Aus dem obigen Prozess können wir ersehen, dass bei der sitzungsbasierten Authentifizierung das Frontend nicht aktiv teilnehmen muss. Die wichtigsten Operationen werden zwischen dem Browser und dem Server abgewickelt.

Vor- und Nachteile

Vorteile

• Einfach und leicht zu bedienen: Die Verwaltung von Sitzungen und Benutzerauthentifizierung ist für Entwickler relativ unkompliziert.
• Gute Kompatibilität: Die meisten Browser unterstützen Cookies, wodurch das automatische Senden und Empfangen ermöglicht wird.

Nachteile

• Schlechte Skalierbarkeit: In verteilten Systemen müssen möglicherweise mehrere Server den Sitzungsspeicher gemeinsam nutzen, was die Komplexität erhöht.
• Erfordert HTTPS: Wenn Cookies gestohlen werden, kann dies zu einer Sitzungsübernahme führen. Daher sollte HTTPS verwendet werden, um die Datenübertragung zu sichern, zusammen mit zusätzlichen Sicherheitsmaßnahmen (z. B. das Setzen von Cookies mit den Attributen HttpOnly und Secure).

Beispielcode

Hier ist ein Beispiel für die Implementierung der Sitzungsauthentifizierung mit Express:

const express = require('express');
const session = require('express-session');
const app = express();

// Konfigurieren und Verwenden der Express-Session-Middleware
app.use(
  session({
    secret: 'your-secret-key', // Schlüssel zum Signieren des Sitzungs-ID-Cookies, um die Sitzungssicherheit zu gewährleisten
    resave: false, // Ob die Sitzung bei jeder Anfrage gespeichert werden soll, auch wenn sie sich nicht geändert hat
    saveUninitialized: true, // Ob eine nicht initialisierte Sitzung gespeichert werden soll
    cookie: {
      secure: true, // Ob Cookies nur über HTTPS gesendet werden sollen (erfordert HTTPS-Unterstützung)
      maxAge: 24 * 60 * 60 * 1000, // Cookie-Ablaufzeit (auf 24 Stunden eingestellt)
    },
  })
);

// Routenhandler für die Anmeldung
app.post('/login', (req, res) => {
  // Benutzer authentifizieren (davon ausgehend, dass der Benutzer validiert wurde)
  const user = { id: 123 }; // Beispiel-Benutzer-ID
  req.session.userId = user.id; // Benutzer-ID in der Sitzung speichern
  res.send('Anmeldung erfolgreich');
});

app.get('/dashboard', (req, res) => {
  if (req.session.userId) {
    // Wenn die Sitzung eine Benutzer-ID enthält, ist der Benutzer angemeldet
    res.send('Dashboard-Inhalt...');
  } else {
    // Wenn in der Sitzung keine Benutzer-ID gefunden wird, ist der Benutzer nicht angemeldet
    res.send('Bitte anmelden...');
  }
});

app.listen(3000, () => {
  console.log('Server listening on port 3000...');
});

JWT-Authentifizierung (JSON Web Token)

Was ist JWT-Authentifizierung?

Die JWT-Authentifizierung ist derzeit eine der am häufigsten verwendeten Authentifizierungsmethoden.

Der Server gibt ein Token zurück, das die Benutzeridentität repräsentiert. Bei Anfragen wird das Token zur Benutzerüberprüfung zu den Anfrageheadern hinzugefügt.

Da HTTP-Anfragen zustandslos sind, wird diese Methode auch als zustandslose Authentifizierung bezeichnet.

Wie JWT funktioniert

1. Benutzeranmeldung: Der Benutzer gibt seine Anmeldeinformationen (z. B. Benutzername und Passwort) auf der Anmeldeseite ein, und diese Anmeldeinformationen werden zur Validierung an den Backend-Server gesendet.
2. JWT generieren: Nach der Validierung der Benutzeranmeldeinformationen generiert der Backend-Server ein JWT. Dieses Token enthält typischerweise grundlegende Benutzerinformationen (z. B. Benutzer-ID) und Metadaten (z. B. Ablaufzeit).
3. JWT zurückgeben: Der Server sendet das generierte JWT zurück an das Frontend, normalerweise in einer JSON-Antwort.
4. JWT speichern: Das Frontend speichert das JWT clientseitig, typischerweise in localStorage. In seltenen Fällen kann es in Cookies gespeichert werden, aber dies birgt Sicherheitsrisiken wie Cross-Site Scripting (XSS) und Cross-Site Request Forgery (CSRF).
5. JWT für Anfragen verwenden: Bei API-Aufrufen hängt das Frontend das JWT-Token im Authorization-Header an (Format: Bearer <token>) und sendet es an den Server.
6. JWT validieren: Nach Erhalt der Anfrage extrahiert der Server das JWT, überprüft seine Gültigkeit (z. B. Überprüfung der Signatur und Ablaufzeit). Wenn es gültig ist, verarbeitet der Server die Anfrage und gibt die entsprechende Ressource oder Daten zurück.
7. Auf die Anfrage antworten: Der Server bearbeitet die Anfrage und gibt eine Antwort zurück, die das Frontend nach Bedarf verwenden kann.

Vor- und Nachteile

Vorteile

• Zustandslos: JWTs sind in sich geschlossen, was bedeutet, dass der Server keine Sitzungsinformationen speichern muss, was die Skalierbarkeit und den Lastenausgleich vereinfacht.
• Cross-Domain-Unterstützung: JWT kann in Cross-Origin-Anfragen verwendet werden (z. B. wenn APIs und Frontends getrennt sind).

Nachteile

• Sicherheitsbedenken: Die Sicherheit von JWT hängt vom Schlüsselschutz und der Token-Ablaufverwaltung ab. Wenn ein JWT gestohlen wird, kann dies Sicherheitsrisiken bergen.

Beispielcode

Hier ist ein Beispiel für die Implementierung der JWT-Authentifizierung mit Express:

const express = require('express');
const jwt = require('jsonwebtoken');
const bodyParser = require('body-parser');
const app = express();

app.use(bodyParser.json());

const secretKey = 'your-secret-key'; // Geheimer Schlüssel zum Signieren und Verifizieren von JWTs

// Anmelderoute, die ein JWT generiert
app.post('/login', (req, res) => {
  const { username, password } = req.body;
  // Benutzerauthentifizierung (davon ausgehend, dass der Benutzer gültig ist)
  const user = { id: 1, username: 'user' }; // Beispiel-Benutzerdaten
  const token = jwt.sign(user, secretKey, { expiresIn: '24h' }); // JWT generieren
  res.json({ token }); // JWT zurückgeben
});

// Geschützte Route
app.get('/dashboard', (req, res) => {
  const token = req.headers['authorization']?.split(' ')[1];
  if (!token) {
    return res.status(401).send('Kein Token bereitgestellt');
  }
  jwt.verify(token, secretKey, (err, decoded) => {
    if (err) {
      return res.status(401).send('Ungültiges Token');
    }
    res.send('Dashboard-Inhalt');
  });
});

app.listen(3000, () => {
  console.log('Server listening on port 3000...');
});

SSO-Authentifizierung (Single Sign-On)

Was ist SSO-Authentifizierung?

Die SSO-Authentifizierung wird häufig in "Suite-basierten" Anwendungen verwendet. Durch ein zentrales Anmeldesystem können sich Benutzer einmal anmelden und Zugriff auf mehrere Anwendungen erhalten, ohne sich erneut authentifizieren zu müssen.

Wie SSO funktioniert

1. Benutzer greift auf eine Anwendung zu: Der Benutzer versucht, auf eine Anwendung zuzugreifen, die eine Authentifizierung erfordert (als Service Provider (SP) bezeichnet).
2. Weiterleitung zum Identitätsanbieter (IdP): Da der Benutzer nicht angemeldet ist, leitet die Anwendung ihn an einen SSO-Identitätsanbieter (IdP) weiter (allgemein als Login Center bezeichnet). Das Login Center übernimmt die Benutzerauthentifizierung.
3. Benutzer meldet sich an: Der Benutzer gibt seine Anmeldeinformationen im Login Center ein. Wenn er bereits angemeldet ist (z. B. im internen SSO-System des Unternehmens), kann er diesen Schritt möglicherweise überspringen.
4. SSO-Token-Generierung: Nach der Authentifizierung generiert der Identitätsanbieter ein SSO-Token (z. B. ein OAuth-Token oder eine SAML-Assertion) und leitet den Benutzer zurück zur ursprünglichen Anwendung, wobei er das Token anhängt.
5. Token-Validierung: Die Anwendung (Service Provider) empfängt das Token und sendet es zur Validierung an den SSO-Identitätsanbieter. Der IdP überprüft das Token und gibt die Identitätsinformationen des Benutzers zurück.
6. Benutzer erhält Zugriff: Nach erfolgreicher Authentifizierung gewährt die Anwendung Zugriff basierend auf den Identitätsinformationen des Benutzers. Der Benutzer kann nun auf die geschützten Ressourcen der Anwendung zugreifen.
7. Zugriff auf andere Anwendungen: Wenn der Benutzer auf andere Anwendungen zugreift, die ebenfalls dasselbe Login Center verwenden, wird er dorthin weitergeleitet. Da er bereits angemeldet ist, authentifiziert ihn das Login Center automatisch und leitet ihn zurück zur Zielanwendung, wodurch eine nahtlose Anmeldung ermöglicht wird.

Vor- und Nachteile

Vorteile

• Vereinfacht die Benutzererfahrung: Benutzer müssen sich nur einmal anmelden, um auf mehrere Anwendungen zuzugreifen, wodurch sich wiederholende Anmeldeversuche reduziert werden.
• Zentralisierte Verwaltung: Administratoren können Benutzeridentitäten und Zugriffsberechtigungen zentral verwalten, was die Effizienz und Sicherheit verbessert.
• Erhöhte Sicherheit: Reduziert das Risiko von Passwortlecks, da sich Benutzer nur ein Passwort merken müssen. Es können auch stärkere Authentifizierungsmechanismen (z. B. Multi-Faktor-Authentifizierung, MFA) erzwungen werden.

Nachteile

• Single Point of Failure: Wenn das Login Center (SSO-Identitätsanbieter) auf ein Problem stößt, können alle darauf basierenden Anwendungen betroffen sein.
• Komplexe Implementierung: Das Bereitstellen und Verwalten einer SSO-Lösung kann komplex sein und erfordert ordnungsgemäße Sicherheitskonfigurationen und Interoperabilität zwischen Systemen.

Häufige SSO-Implementierungstechnologien

SAML (Security Assertion Markup Language)

• Ein XML-basierter Standard, der für den Austausch von Authentifizierungs- und Autorisierungsdaten zwischen Identitätsanbietern (IdPs) und Dienstanbietern (SPs) verwendet wird.
• Wird häufig in Unternehmensumgebungen verwendet.

OAuth 2.0 & OpenID Connect

• OAuth 2.0 ist ein Autorisierungs-Framework zum Gewähren von Drittanbieterzugriff auf Benutzerressourcen.
• OpenID Connect baut auf OAuth 2.0 auf und fügt eine Identitätsebene für die Benutzerauthentifizierung hinzu.
• Wird häufig in Web- und mobilen Anwendungen verwendet.

CAS (Central Authentication Service)

• Eine Open-Source-SSO-Lösung für Webanwendungen, die es Benutzern ermöglicht, sich einmal zu authentifizieren und auf mehrere Dienste zuzugreifen.

OAuth 2.0-Authentifizierung

Was ist OAuth 2.0-Authentifizierung?

OAuth 2.0 ist ein Standardprotokoll, das zum Autorisieren von Drittanbieteranwendungen für den Zugriff auf Benutzerressourcen verwendet wird. Beispiele hierfür sind:

• Facebook-Anmeldung
• Discord-Anmeldung
• App-QR-Code-Anmeldung

OAuth 2.0 ist in erster Linie für die Autorisierung und nicht für die Authentifizierung konzipiert, wird aber häufig mit der Authentifizierung kombiniert, um die Benutzeranmeldung zu ermöglichen.

Wie OAuth 2.0 funktioniert

OAuth 2.0 ist komplex, daher müssen wir, bevor wir seinen Ablauf verstehen, einige Schlüsselkonzepte klären.

Schlüsselkonzepte in OAuth 2.0

• Ressourceninhaber: Typischerweise der Benutzer, dem die geschützte Ressource gehört (z. B. persönliche Daten, Dateien).
• Ressourcenserver: Der Server, der die geschützten Ressourcen hostet und sicherstellt, dass sie nur für autorisierte Benutzer zugänglich sind.
• Client: Die Anwendung oder der Dienst, der auf die geschützte Ressource zugreifen möchte. Der Client muss die Autorisierung des Ressourceninhabers einholen.
• Autorisierungsserver: Der Server, der für die Authentifizierung des Ressourceninhabers und die Gewährung der Autorisierung an den Client verantwortlich ist. Er stellt Zugriffstoken aus, die es dem Client ermöglichen, auf den Ressourcenserver zuzugreifen.

OAuth 2.0-Workflow

1. Benutzer erteilt Autorisierung: Wenn der Benutzer mit einer Clientanwendung interagiert, fordert die Anwendung die Autorisierung für den Zugriff auf die Ressourcen des Benutzers an. Der Benutzer wird an den Autorisierungsserver weitergeleitet.
2. Autorisierungscode abrufen: Wenn der Benutzer zustimmt, generiert der Autorisierungsserver einen Autorisierungscode und sendet ihn (über eine Weiterleitungs-URL) an den Client zurück.
3. Zugriffstoken abrufen: Der Client tauscht den Autorisierungscode gegen ein Zugriffstoken aus, indem er eine Anfrage an den Autorisierungsserver sendet.
4. Auf Ressourcen zugreifen: Der Client verwendet das Zugriffstoken, um geschützte Ressourcen vom Ressourcenserver anzufordern. Der Ressourcenserver validiert das Token und gibt die angeforderten Daten zurück.

Häufige OAuth 2.0-Gewährungstypen (Autorisierungsflüsse)

1. Autorisierungscode-Fluss (am häufigsten)

   • Geeignet für Webanwendungen, die eine Benutzerinteraktion erfordern.
   • Der Client tauscht den Autorisierungscode nach Einholung der Nutzereinwilligung gegen ein Zugriffstoken aus.

2. Impliziter Fluss (nicht empfohlen)

   • Entwickelt für öffentliche Clients (z. B. Single-Page-Anwendungen).
   • Der Benutzer erhält direkt ein Zugriffstoken anstelle eines Autorisierungscodes.
   • Aufgrund von Sicherheitsbedenken wird dieser Fluss nicht mehr empfohlen.

3. Ressourceninhaber-Passwortanmeldeinformationen-Fluss (eingeschränkte Verwendung)

   • Der Benutzer gibt seinen Benutzernamen und sein Passwort direkt an den Client weiter.
   • Der Client fordert mit diesen Anmeldeinformationen ein Zugriffstoken an.
   • Aufgrund von Sicherheitsrisiken nicht für öffentlich zugängliche Anwendungen empfohlen.

4. Client-Anmeldeinformationen-Fluss (Machine-to-Machine)

   • Wird verwendet, wenn eine Clientanwendung auf ihre eigenen Ressourcen zugreifen muss, anstatt im Namen eines Benutzers zu handeln.
   • Üblich für den API-Zugriff zwischen Diensten.

Vor- und Nachteile

Vorteile

• Flexibilität: Unterstützt mehrere Autorisierungsflüsse und ist somit für verschiedene Clienttypen und Anwendungsszenarien geeignet.
• Sicherheit: Durch die Trennung von Autorisierung und Authentifizierung erhöht OAuth 2.0 die Sicherheit. Anstelle von Benutzernamen und Passwörtern werden Token zur Zugriffskontrolle verwendet.

Nachteile

• Komplexität: Das Implementieren und Konfigurieren von OAuth 2.0 kann eine Herausforderung sein und erfordert eine ordnungsgemäße Token-Verwaltung und Sicherheitskonfiguration.
• Sicherheitsrisiken: Wenn ein Token durchsickert, kann dies ein Sicherheitsrisiko darstellen. Daher müssen geeignete Sicherheitsmaßnahmen (z. B. die Verwendung von HTTPS und sichere Token-Verwaltungsstrategien) vorhanden sein.

Beispielcode

Hier ist eine Express-Implementierung der OAuth 2.0-Authentifizierung:

const express = require('express');
const axios = require('axios');
const app = express();

// OAuth 2.0-Konfiguration
const clientId = 'your-client-id';
const clientSecret = 'your-client-secret';
const redirectUri = 'http://localhost:3000/callback';
const authorizationServerUrl = 'https://authorization-server.com';
const resourceServerUrl = 'https://resource-server.com';

// Anmelderoute - Leitet den Benutzer an den Autorisierungsserver weiter
app.get('/login', (req, res) => {
  const authUrl = `${authorizationServerUrl}/authorize?response_type=code&client_id=${clientId}&redirect_uri=${redirectUri}&scope=read`;
  res.redirect(authUrl);
});

// Callback-Route - Behandelt den Austausch des Autorisierungscodes
app.get('/callback', async (req, res) => {
  const { code } = req.query;
  if (!code) {
    return res.status(400).send('Autorisierungscode fehlt');
  }

  try {
    // Autorisierungscode gegen ein Zugriffstoken austauschen
    const response = await axios.post(`${authorizationServerUrl}/token`, {
      grant_type: 'authorization_code',
      code,
      redirect_uri: redirectUri,
      client_id: clientId,
      client_secret: clientSecret,
    });

    const { access_token } = response.data;

    // Zugriffstoken zum Abrufen geschützter Ressourcen verwenden
    const resourceResponse = await axios.get(`${resourceServerUrl}/user-info`, {
      headers: { Authorization: `Bearer ${access_token}` },
    });

    res.json(resourceResponse.data);
  } catch (error) {
    res.status(500).send('Fehler beim Token-Austausch oder beim Zugriff auf Ressourcen');
  }
});

app.listen(3000, () => {
  console.log('Server listening on port 3000...');
});

Fazit

Jede dieser vier Authentifizierungsmethoden hat ihre eigenen Vorteile, Nachteile und geeigneten Anwendungsfälle:

• Session: Ideal für einfache, serverseitig gerenderte Anwendungen.
• JWT: Geeignet für moderne, zustandslose Architekturen und mobile Apps.
• SSO: Am besten für Unternehmensumgebungen mit mehreren zugehörigen Diensten geeignet.
• OAuth 2.0: Die bevorzugte Wahl für Integrationen von Drittanbietern und API-Zugriff.

---

Wir sind Leapcell, Ihre erste Wahl für das Hosten von Node.js-Projekten.

Leapcell ist die Serverless-Plattform der nächsten Generation für Webhosting, asynchrone Aufgaben und Redis:

Multi-Sprachen-Unterstützung

• Entwickeln Sie mit Node.js, Python, Go oder Rust.

Stellen Sie unbegrenzt Projekte kostenlos bereit

• Zahlen Sie nur für die Nutzung – keine Anfragen, keine Gebühren.

Unschlagbare Kosteneffizienz

• Pay-as-you-go ohne Leerlaufgebühren.
• Beispiel: 25 $ unterstützt 6,94 Mio. Anfragen bei einer durchschnittlichen Antwortzeit von 60 ms.

Optimierte Entwicklererfahrung

• Intuitive Benutzeroberfläche für mühelose Einrichtung.
• Vollautomatische CI/CD-Pipelines und GitOps-Integration.
• Echtzeitmetriken und -protokollierung für umsetzbare Einblicke.

Mühelose Skalierbarkeit und hohe Leistung

• Auto-Skalierung zur mühelosen Bewältigung hoher Parallelität.
• Kein operativer Aufwand – konzentrieren Sie sich einfach auf das Erstellen.

Erfahren Sie mehr in der Dokumentation!

Folgen Sie uns auf X: @LeapcellHQ