JWT

JSON Web Token (JWT) ist ein verschlüsseltes Tokenformat, das Authentifizierungs- und Autorisierungsdaten sicher zwischen zwei Anwendungen überträgt. In Document360 wird JWT verwendet, um Leser-Logins auf Ihrer Wissensdatenbank zu authentifizieren.

Document360 verwendet einen ähnlichen Ansatz wie PKCE (Proof Key for Code Exchange, eine sichere OAuth-Methode), um das JWT-Token zu erzeugen.

Wann man JWT NICHT verwenden sollte

JWT ist nicht die richtige Wahl, wenn:

• Ihre Organisation nutzt bereits einen zentralen Identitätsanbieter (Okta, Microsoft Entra, Google Workspace) und möchte, dass die Leser sich über diesen authentifizieren. Verwenden Sie stattdessen SAML oder OpenID Connect. Dazu lesen Sie Single Sign-On (SSO).
• Sie benötigen Funktionen wie das automatische Registrieren von SSO-Lesern, Selbstregistrierung der Leser oder das Überspringen der gemeinsamen Anmeldeseite von Document360. Diese Funktionen werden mit JWT nicht unterstützt.
• Du brauchst eine Benutzer-(Portal-)Authentifizierung. JWT unterstützt nur die Leser-Authentifizierung auf der Wissensdatenbank-Seite.

JWT vs SAML vs OpenID Connect

Wie die JWT-Authentifizierung funktioniert

Das untenstehende Diagramm zeigt den vollständigen JWT-Authentifizierungsfluss zwischen Ihrer Anwendung, dem Document360-Identitätsserver und der Wissensdatenbank-Website.

Schlüsselterminologie

Authentifizierungsablauf

1. Der Nutzer greift auf die private Wissensdatenbank zu. Document360 erkennt, dass das JWT-SSO aktiviert ist, und leitet den Benutzer auf die in den JWT-Einstellungen konfigurierte Anmelde-URL weiter.
2. Der Nutzer meldet sich in Ihrer Anwendung an. Wenn der Nutzer noch nicht authentifiziert ist, übernimmt deine Login-Seite die Authentifizierung.
3. Dein Backend verlangt einen einmaligen Authentifizierungscode. Ihr Backend sendet eine POST Anfrage an die Code-Generierungs-URL mit der Identität des Nutzers, optional readerGroupIdsund tokenValidity innerhalb von Minuten. Diese Anfrage muss über HTTP Basic Auth mit Ihrer Client-ID und Client Secret autorisiert werden.

Beispiel für Autorisierungsheader

Authorization: Basic Base64Encode(clientId:clientSecret)

Beispiel JSON-Nutzlasten

{
  "username": "firstname + lastname",
  "firstName": "firstname",
  "lastName": "lastname",
  "emailId": "user email",
  "readerGroupIds": ["Obtain from Reader groups overview page in the Document360 portal (Optional)"],
  "tokenValidity": 15
}

4. Der Document360 Identity-Server liefert einen Authentifizierungscode. Wenn die Anfrage gültig ist, generiert der Identitätsserver von Document360 einen Einmal-Autorisierungscode und sendet ihn an Ihr Backend zurück.
5. Deine App leitet den Nutzer zurück zu Document360 weiter. Dein Backend hängt den Code an die Callback-URL an und leitet den Nutzer dorthin weiter. Zum Beispiel: https://yourproject.document360.io/jwt/authorize?code=xyz

6. Document360 validiert den Code. Document360 sendet es über einen Backchannel an den Identitätsserver, um es gegen ein JWT-Token auszutauschen.
7. Eine Lesersitzung wird erstellt. Document360 extrahiert Benutzerinformationen und Zugriffsregeln basierend auf readerGroupIds dem Token. Für den Leser wird eine Sitzung erstellt, die ihm Zugriff auf die erlaubten Kategorien, Sprachen oder Versionen gewährt.

Tokenvalidität und Sitzungsverhalten

• Du kannst die Sitzungsdauer anhand des Feldes tokenValidity im Payload definieren (mindest: 5 Minuten, maximal: 1440 Minuten).
• Sobald das Token abläuft, wird der Leser zurück zu Ihrer Anmelde-URL weitergeleitet.
• Wenn der Benutzer weiterhin in Ihrer App authentifiziert ist, wird ein neuer Code generiert und die Sitzung nahtlos wiederhergestellt.

Fang mit JWT an

FAQ