Autorisierung mit JSON Web Token (JWT)

Authentifizierung vs. Autorisierung

Authentifizierung befasst sich mit der Identitätsprüfung. Es geht darum, zu bestätigen, wer ein Benutzer wirklich ist. Dies geschieht in der Regel durch die Eingabe von Anmeldeinformationen wie Benutzername und Passwort. Erfolgreiche Authentifizierung bedeutet, dass der Benutzer diejenige Person ist, die er vorgibt zu sein.

Autorisierung hingegen konzentriert sich auf die Berechtigungsverwaltung. Nachdem die Identität verifiziert wurde, stellt die Autorisierung fest, ob der momentane Benutzer tatsächlich der ist, der sich angemeldet hat und welche Aktionen oder Ressourcen der authentifizierte Benutzer innerhalb der Anwendung ausführen darf.

Die Authentifizierung erfolgt meist zu Beginn einer Benutzersitzung, beispielsweise durch die Anmeldung auf einer Website. Nach erfolgreicher Authentifizierung wird für den Rest der Sitzung ein Autorisierungsprozess benötigt, der die Identität bezeugt und die Berechtigung für die aufgerufenen Inhalte feststellt.

Ablauf einer Authorisierung ohne JWT

1. Anmeldevorgang:
   • Benutzer gibt Anmeldeinformationen (z.B. Benutzername, Passwort) ein.
   • Server verifiziert die Anmeldeinformationen in einer Datenbank oder anderen Authentifizierungssystemen.
   • Bei erfolgreicher Authentifizierung wird eine Session auf dem Server gespeichert und dem Benutzer eine Session-ID zugewiesen.
   • Diese Session-ID wird mit einem Cookie an den Benutzer zurück geschickt.
2. Ressourcenanfrage:
   • Benutzer sendet eine Anfrage an eine Ressource der Anwendung.
   • Die Anfrage enthält die Session-ID im Header oder Cookie.
3. Autorisierungsprüfung:
   • Der Server extrahiert die Session-ID aus der Anfrage.
   • Mit der Session-ID wird der aktuelle Zustand der Benutzersitzung und die Berechtigungen des Benutzers aus einer Datenbank oder einem anderen Speichersystem abgerufen.
   • Der Server prüft, ob der Benutzer die Berechtigung zum Zugriff auf die angeforderte Ressource hat.
4. Zugriffssteuerung:
   • Ist der Benutzer autorisiert, wird die Ressource an den Benutzer ausgeliefert.
   • Ist der Benutzer nicht autorisiert, wird ihm eine Fehlermeldung angezeigt und der Zugriff auf die Ressource verweigert.

Nachteile der Autorisierung ohne JWT:

• Mangelnde Sicherheit: Session-Cookies und andere Verfahren können anfälliger für Angriffe wie Session-Hijacking und Cross-Site Scripting (XSS) sein.
• Statusabhängigkeit: Server müssen den Status der Benutzersitzungen verwalten, was zu Skalierungsproblemen führen kann.
• Keine plattformübergreifende Unterstützung: Session-Cookies und andere Verfahren funktionieren möglicherweise nicht in allen Umgebungen, z. B. in mobilen Apps.

Ablauf einer Authorisierung mit JWT

1. Anmeldevorgang:
   • Benutzer gibt Anmeldeinformationen (z.B. Benutzername, Passwort) ein.
   • Server verifiziert die Anmeldeinformationen in einer Datenbank oder anderen Authentifizierungssystemen.
   • Bei erfolgreicher Authentifizierung generiert der Server ein JWT, das die Benutzer-ID, Berechtigungen und andere relevante Informationen enthält.
   • Das JWT wird mit einem geheimen Schlüssel signiert und an den Client-Browser des Benutzers zurückgegeben.
2. Speicherung des JWT:
   • Das JWT wird in einem sicheren HTTP-Only-Cookie auf dem Client-Gerät gespeichert.
   • Alternativ kann das JWT auch im Local Storage oder in einer anderen sicheren Speicherung auf dem Client-Gerät abgelegt werden.
3. Ressourcenanfrage:
   • Der Benutzer sendet eine Anfrage an eine Ressource der Anwendung.
   • Die Anfrage enthält das JWT im Authorization-Header.
4. Autorisierungsprüfung:
   • Der Server extrahiert das JWT aus dem Authorization-Header
   • Der Server verifiziert die Signatur des JWTs mit dem geheimen Schlüssel.
   • Ist die Signatur gültig, dekodiert der Server das JWT und extrahiert die Benutzer-ID und Berechtigungen aus der Payload.
   • Der Server prüft, ob der Benutzer die Berechtigung zum Zugriff auf die angeforderte Ressource hat.
5. Zugriffssteuerung:
   • Ist der Benutzer autorisiert, wird die Ressource an den Benutzer ausgeliefert.
   • Ist der Benutzer nicht autorisiert, wird ihm eine Fehlermeldung angezeigt und der Zugriff auf die Ressource verweigert.
6. Sitzungsaktualisierung:
   • Bevor das JWT abläuft, kann der Client ein Refresh-Token an den Server senden, um ein neues JWT mit aktualisierter Gültigkeitsdauer zu erhalten.
   • Dies ermöglicht eine unterbrechungsfreie Benutzersitzung, ohne dass sich der Benutzer erneut anmelden muss.

Vorteile der Autorisierung mit JWT:

• Verbesserte Sicherheit: JWTs sind durch digitale Signaturen geschützt, was sie vor Fälschungen und Manipulationen bewahrt.
• Unabhängigkeit vom Serverstatus: JWTs erfordern keinen Serverstatus, da alle notwendigen Informationen im Token selbst enthalten sind.
• Skalierbarkeit: JWTs eignen sich gut für skalierbare Anwendungen, da sie keine serverseitige Speicherung von Sitzungsinformationen erfordern.
• Plattformübergreifende Unterstützung: JWTs können in verschiedenen Umgebungen, z. B. in Webanwendungen, mobilen Apps und APIs, verwendet werden.

Aufbau eines JWT

Ein JWT besteht aus drei mit Base64 codierten Segmenten, die durch einen Punkt getrennt sind - z.B.:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

1. Header:
   Im Header werden Informationen zur Art des Token und zum verwendeten Algorithmus für die Signatur-Prüfung gespeichert.
2. Payload:
   Der Payload besteht aus allen relevanten Informationen, die im Token festgehalten werden sollen. In erster Linie wird das eine User-ID und eine Expiration Time für den Token sein.
3. Signatur:
   In der Signatur werden die ersten beiden Segmente zusammen mit dem geheimen Schlüssel über den im Header festgelegten Algorithmus kodiert.

Prüfung eines JWT

Bei der Prüfung des JWT werden das Base64 codierte Header- und Payload-Segment mit einem Punkt verbunden und wieder zusammen mit dem - auf dem Server - hinterlegten Schlüssel und dem festgelegten Algorithmus codiert. Entspricht das Ergebnis dem letzten Segment des Token, war die Prüfung erfolgreich und der Token wurde seit seiner Erstellung nicht manipuliert.