Staatenlose und zustandsbehaftete Architektur

Bezieht sich auf den Status der Anwendung, d. h. auf den Zustand oder die Qualität der Anwendung zu einem bestimmten Zeitpunkt. Bei der zustandslosen Authentifizierung wird keine Sitzung oder kein Benutzer gespeichert, sondern nur statische Inhalte. Dies unterscheidet sich von Stateful, bei dem es sich um dynamischen Inhalt handelt.

Ein zustandsloser Prozess ist eine isolierte Ressource, die keinen anderen Dienst oder keine Interaktion mit einem anderen System referenziert. Es funktioniert nur in diesem Teil des Codes, ohne Informationen aus alten Transaktionen mitzubringen, da die zustandslose Authentifizierung diese Art von Daten nicht speichert; Jeder Vorgang wird von Grund auf neu durchgeführt.

Die zustandsbehaftete Authentifizierung ermöglicht die mehrmalige Verwendung von Informationen und wird basierend auf dem Kontext früherer Transaktionen ausgeführt. Daher wird in Anwendungen, in denen auf eine Antwort oder bereits vorhandene Daten gewartet werden muss, unabhängig davon, ob sie in einem anderen System oder einer anderen Datenbank vorhanden sind, Stateful verwendet.

Zustandslose Authentifizierung

Die zustandslose Authentifizierung besteht aus einer Strategie, bei der der Benutzer nach der Bereitstellung von Anmeldeinformationen als Antwort ein Zugriffstoken erhält. Dieses Token enthält bereits alle Informationen, die zur Identifizierung des Benutzers erforderlich sind, der es generiert hat, ohne dass ständig der Dienst, der das Token ausgegeben hat, oder eine Datenbank konsultiert werden müssen.

Dieses Token wird clientseitig (Browser) gespeichert, sodass der Server nur die Möglichkeit hat, die Gültigkeit des Tokens zu überprüfen, indem er bestätigt, dass Nutzlast und Signatur übereinstimmen.

Zustandslose Authentifizierung JWT

JSON Web Token (JWT) sind Schlüssel mit in RFC-7519 festgelegten Standards, die eine Entität in Form von Deklarationen enthalten, die unabhängig sind, ohne dass die aufgerufen werden müssen Server, um das Token erneut zu validieren.

Sind Zeichenfolgen, die im Base64-Standard mit einem geheimen Schlüssel codiert sind, wie im Beispiel:

Vor- und Nachteile

Vorteile:

• Geringer Serverspeicherverbrauch.
• Ausgezeichnet in Bezug auf Skalierbarkeit.
• Ideal für verteilte Anwendungen wie APIs und Microservices.
• Erzeugung und Verteilung des Tokens in einer isolierten Anwendung, ohne Abhängigkeit von Dritten.
• Einfache Interpretation und Validierung von Token-Benutzerdaten.

Nachteile:

• Schwierigkeiten bei der Zugangskontrolle.
• Es ist nicht möglich, den Token jederzeit einfach zu widerrufen.
• Es kann das Eindringen böswilliger Dritter erleichtern, wenn jemand Zugriff auf den Token hat.
• Die Sitzung kann nicht geändert werden, bis das Token abläuft.
• Das JWT-Token ist komplexer und kann in zentralisierten Anwendungen wie Monolithen unnötig werden.

Zustandsbehaftete Authentifizierung

Wird häufig in verschiedenen Anwendungen verwendet, insbesondere in solchen, die nicht so viel Skalierbarkeit erfordern. Die zustandsbehaftete Sitzung wird im Back-End der Anwendung erstellt und die Sitzungsreferenz wird an den entsprechenden Benutzer zurückgesendet . Jedes Mal, wenn der Benutzer eine Anfrage stellt, generiert ein Teil der Anwendung das Token. Von diesem Moment an wird dieser Token bei jeder neuen Anfrage erneut an die Anwendung gesendet, um den Zugriff erneut zu validieren. Bei diesem Modell kann das Token problemlos widerrufen werden, wenn sich die Benutzerdaten ändern.

Dies sind undurchsichtige Zugriffstoken, d. h. eine einfache Zeichenfolge in einem proprietären Format, die keine Kennung oder Benutzerdaten in Bezug auf dieses Token enthält. Der Empfänger muss den Server anrufen, der das Token erstellt hat, um es zu validieren.

Beispiel-Token: 8c90e55a-e867-45d5-9e42-8fcbd9c30a74

Diese ID muss in einer Datenbank mit dem Benutzer gespeichert werden, der Eigentümer des Tokens ist.

Vor- und Nachteile

Vorteile:

• Zentralisierte Implementierungslogik.
• Vereinfachte Zugriffsverwaltung und -kontrolle.
• Hervorragend geeignet für Monolithen, MVC-Anwendungen und interne Prozesse.
• Sicherer vor böswilligen Dritten.

Nachteile:

• Möglicherweise liegt eine Überlastung in der API vor, die für die Validierung des Tokens verantwortlich ist.
• Fehler hinsichtlich der Skalierbarkeit.
• Größere Schwierigkeiten bei der Verteilung der Authentifizierung zwischen Mikrodiensten.
• Wenn in einer verteilten Anwendung der Authentifizierungsdienst ausfällt, sind alle anderen Dienste nicht verfügbar.
• Größere Implementierungskomplexität.
• Größere Schwierigkeiten bei der Integration mit Drittsystemen.

Wann sollte jeder Ansatz verwendet werden?

Wann sollten ein JWT-Token und eine zustandslose Authentifizierung verwendet werden?

• Wenn eine höhere Leistung erforderlich ist, ohne sich Gedanken über eine Überlastung einer API machen zu müssen.
• Wenn mehrere Kommunikationen zwischen Diensten verteilt sind.
• Wenn es notwendig ist, zu identifizieren, welcher Benutzer eine Aktion im System in verschiedenen Diensten ausführt.
• Wenn nicht beabsichtigt ist, die Daten eines Benutzers beizubehalten, sondern nur seine Erstregistrierung.
• Wenn es notwendig ist, einen externen Zugriff auf den Dienst zu generieren.
• Wenn es notwendig ist, die Daten derjenigen zu manipulieren, die eine bestimmte Aktion ausführt, mit minimalen Auswirkungen auf das System.

Wann sollten ein undurchsichtiges Token und eine zustandsbehaftete Authentifizierung verwendet werden?

• Wenn eine vollständige Zugriffskontrolle der Benutzer eines Systems erforderlich ist, hauptsächlich um die Zugriffshierarchie zu definieren.
• In einer zentralen Anwendung, ohne verteilte Dienste und ohne Kommunikation mit externen Diensten.

Abschließende Überlegungen:

• An manchen Stellen, beispielsweise bei „API-Stress“, kann der Begriff aus Gründen der Klarheit durch „API-Overhead“ ersetzt werden.
• Der Abschnitt über „JWT-Token“ könnte eine detailliertere Erläuterung der in RFC-7519 genannten „Erklärungen“ enthalten, wenn die Zielgruppe mehr Kontext benötigt.
• Im Abschnitt zur zustandsbehafteten Authentifizierung könnte der Satz „ein Teil der Anwendung generiert das Token“ präzisiert werden, indem erklärt wird, welcher spezifische Teil der Anwendung dafür verantwortlich ist.