Authentifikation & Autorisierung

Authentifizierung (mit JWT)

Einleitung

Was ist JWT?

JSON Web Token (JWT) ist ein offener Standard (RFC 7519), das eine kompakte und eigenständige Methode für die sichere Übertragung von Informationen zwischen Parteien als JSON-Objekt definiert. Diese Informationen können überprüft und vertrauenswürdig sein, da sie digital signiert sind. JWTs können mit einem geheimen Schlüssel signiert werden (mit dem HMAC Algorithmus) oder ein öffentliches/privates Schlüsselpaar mit RSA oder ECDSA.
Session Timeout (bei Benutzerinteraktion) & Auto-Logout (ohne Benutzerinteraktion)

Was ist ein Zugriffstoken?

Zugriffstoken werden bei der tokenbasierten Authentifizierung verwendet, um einer Anwendung den Zugriff auf eine API zu ermöglichen. Die Clientanwendung erhält ein Zugriffstoken, nachdem ein Benutzer den Zugriff erfolgreich authentifiziert und autorisiert hat, und übergibt dann das Zugriffstoken als Anmeldeinformationen, wenn die Ziel-API aufgerufen wird. Der signierte Zugriff token informiert die API, dass der Träger des Tokens autorisiert wurde, auf die API zuzugreifen und bestimmte Aktionen auszuführen, die durch den Bereich angegeben sind, der während der Autorisierung gewährt wurde.

Was ist ein Aktualisierungstoken?

Ein Aktualisierungstoken ist eine spezielle Art von Token, das verwendet wird, um ein erneutes Zugriffstoken zu erhalten. Sie können neue Zugriffstoken nach deren Ablauf anfordern. Anwendungen müssen Aktualisierungen und Zugriff speichern Token sicher, da sie im Wesentlichen speichern und kann ewig verwendet werden (Aktualisieren - Zugriff => Aktualisieren - Zugriff...).

Aktualisierungstoken verbessern die Authentifizierung erheblich. Der Benutzer muss sich nur einmal über den Webauthentifizierungsprozess authentifizieren. Die anschließende erneute Authentifizierung kann ohne Benutzerinteraktion mithilfe des Aktualisierungstokens erfolgen.

TIMs Ansatz zur Verwendung von JWT

JWT-Anrufe

Fast-Track-Dokumentation

Login-Anfrage

• Der Endpunkt /tim/api/auth/login mit HTTP-Methode POST und Body Parameter username + password muss aufgerufen werden, nachdem Sie die folgenden Schritte ausgeführt haben:

  1. Das Passwort MUSS base64-kodiert sein (der Benutzername darf NICHT verschlüsselt sein)

  2. Inhaltstyp: application/x-www-form-urlencoded

  3. Der POST-Text muss Variablen wie username=testuser&password=testpass

Als Ergebnis der Anmeldeanforderung sendet der Server eine Antwort mit 2 generierten Token (accessToken + refreshToken).

Aufrufen einer API

• Stellen Sie sicher, dass Sie über ein Zugriffstoken verfügen, oder senden Sie eine Anmeldeanforderung, um es zu erhalten

• Alle anderen Anfragen an die API müssen gesendet werden, nachdem Sie einen der folgenden Schritte ausgeführt haben:

  • im Vertrauen auf das HttpOnly-Cookie, das nach der Anmeldeanfrage automatisch gesetzt wird

  • die Autorisierung Header muss hinzugefügt werden. Es hat das Format: Bearer AccessToken

Anforderung zum Aktualisieren von Token

• Wenn Ihre Anzahl der Anfragen nicht mehr als ~ 1 pro Stunde beträgt, können Sie Ihr Token nicht aktualisieren, sondern nur eine neue Authentifizierung durchführen (abhängig von Ihrem Modul-Setup)

• Stellen Sie sicher, dass Sie über ein Aktualisierungstoken verfügen, oder senden Sie eine Anmeldeanforderung, um es zu erhalten

• Der POST-Text muss Variablen wie refreshToken=yourRefreshToken

• Der Endpunkt /tim/api/auth/refresh mit HTTP-Methode POST muss aufgerufen werden

Als Ergebnis der Aktualisierungstokenanforderung sendet der Server eine Antwort mit 2 neu generierten Token (accessToken + refreshToken).

Abmeldeanforderung

• Der Endpunkt /tim/api/auth/logout muss aufgerufen werden

• das HttpOnly-Cookie access_token wird automatisch aus dem Browser gelöscht

Aufgrund der Abmeldeanforderung kann der Benutzer nicht auf die Serverressourcen zugreifen, da das HttpOnly-Cookie clientseitig gelöscht wird. Da die Zugriffstoken-Blacklist jedoch nicht in TIM implementiert ist, kann die Autorisierung bis zum Ablauf des Tokens gültig sein, wenn der Benutzer das Zugriffstoken vor der Abmeldung speichern konnte.

Was muss für Systeme, die TIM aufrufen, geändert werden?

Die Systeme müssen die folgenden Schritte ausführen:

• Senden Sie eine Anmeldeanforderung, um ein Token-Paar zu erhalten (Zugriff + Aktualisierung).

• Führen Sie einen der folgenden Schritte aus:

  • im Vertrauen auf das HttpOnly-Cookie, das nach der Anmeldeanfrage automatisch gesetzt wird
    ODER

  • Erstellen Sie einen Authorization-Header und platzieren Sie darin das Zugriffstoken, das während der Anmeldeanforderung als Antwort vom Server empfangen wurde.

• Senden Sie eine Anforderung an die API.

Senden von Anforderungen von der Clientseite

Dieser Teil zeigt Ihnen, wie Anfragen an den Server über Javascript gestellt werden können, mit Beispielen für Authentifizierung und autorisierte Anfragen unter Verwendung des Autorisierungsheaders.

1. Erstellen Sie ein XMLHttpRequest-Objekt, und legen Sie alle erforderlichen Parameter fest, um Anforderungen an den Server auszuführen, wie im folgenden Beispiel gezeigt:

   let Util = { request: function (method, url, parameters, accessToken, callback) { let xhr = new XMLHttpRequest(); if (method.toUpperCase() === "GET" && parameters != null) url += "?" + parameters; xhr.open(method, url); xhr.responseType = "json"; xhr.setRequestHeader("Accept", "application/json"); xhr.onreadystatechange = function () { if (xhr.readyState === 4) { if (callback) callback(xhr); } } if (accessToken !== null) { xhr.setRequestHeader("Authorization", "Bearer " + accessToken); } if (method.toUpperCase() === "POST") { xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded"); xhr.send(parameters); } else { xhr.send(); } return xhr; } };

    

2. Login-Anfrage senden

   $(document).ready(function () { let accessToken; $("#login-btn").click(function (e) { e.preventDefault(); Util.request("POST", "http://localhost:8280/tim/api/auth/login", "username=" + $('#username').val() + "&password=" + $('#password').val(), null, function (jsonCall) { if (jsonCall.status === 200) { accessToken = jsonCall.response.accessToken; } }); });

    

3. Senden einer Anfrage an API

   $("#get-tasks-btn").click(function (e) { e.preventDefault(); Util.request("GET", "http://localhost:8280/tim/api/tasks", "status=open&limit=10&offset=0&mygroup=false", accessToken, function (res) { if (res.status === 500) { alert("Please login first."); } else if (res.status === 200) { console.log(res.response); } }); }); });

Das Beispiel für Webformulare finden Sie in den folgenden Anhängen:

• Webformular mit 2 XmlHttpRequests (Login-Request und API-Request):

Open

• Webformular mit Anmeldeanforderung (XMLHttpRequest) und API-Anforderung (AJAX):

Open

Aufrufen eines Webdiensts

Es kann vorkommen, dass ein System den TIM-Webdienst verwenden muss. Angenommen, das System möchte eine Anforderung zur Archivierung einer Prozessinstanz senden. Um dies zu tun, sollte das System die GenericEntityManager Webservice und die Archiv -Methode, die sich dort befindet.

Beispielsweise wird das SoapUI-Tool verwendet, um eine Webdienstmethode aufzurufen.

Open

Beispiel für einen Webdienstmethodenaufruf

Als weiteres Beispiel kann der Webservice über die Browserkonsole direkt aufgerufen werden. In diesem Fall ist keine Konfiguration erforderlich, da das Zugriffstoken während der Anmeldeanforderung als HttpOnly-Cookie gesetzt wurde und TIM dieses Cookie verwendet, um die Anforderung zu autorisieren.

Open

Beispiel für einen Webdienstaufruf über die Browserkonsole

Ausführliche Dokumentation mit Beispielen

Zunächst ist eine Authentifizierung erforderlich, um Zugriff auf die Serverressourcen zu erhalten. Der Benutzer muss sich am System anmelden, um authentifiziert zu werden.
Wenn der Benutzer in TIM eine Anmeldeanforderung an den Server sendet, sendet der Server eine Antwort, die Zugriffs- und Aktualisierungstoken enthält, und das Zugriffstoken wird ebenfalls auf dem Cookie platziert.

Ein Beispiel für das Abrufen eines JWT-Tokens wird gezeigt, um zu verstehen, wie der Anmeldeprozess intern funktioniert. In diesem Beispiel wird der Postbote als Werkzeug verwendet, um mit dem Server zu kommunizieren, indem die entsprechenden Endpunkte aufgerufen werden.

Nachdem der Postbote geöffnet wurde, müssen einige Parameter ausgefüllt werden, um die Kommunikation mit dem Server vorzubereiten.
Bevor Sie mit der Kommunikation mit dem Server beginnen, müssen Sie eine Liste der Schritte ausführen:

1. Anforderungs-URL ausfüllen
   Zunächst muss das Feld Anforderungs-URL ausgefüllt werden. In diesem Beispiel wird die nächste URL http://localhost:8280/tim/api/auth/login wird verwendet, wenn localhost ein Hostname (IP-Adresse des Hostservers) und Port (die Adresse des Ports, an dem der Hostserver auf Anfragen wartet) ist.

Wenn sich ein Benutzer anmeldet, ruft das System in der Regel die /tim /api/auth/login -Endpunkt, um JWT-Token (ein Paar von Zugriffs- und Aktualisierungstoken) zu generieren und dann eine Authentifizierung durchzuführen. Stellen Sie sicher, dass Sie die HTTP POST-Methode verwenden.

1. Hinzufügen eines benutzerdefinierten Headers

In Postman, wenn die Registerkarte Header geöffnet ist, muss ein zusätzlicher Header hinzugefügt werden.
Als Schlüssel des Headers wird die Inhaltstyp muss als Mehrwert hinzugefügt werden - application/x-www-form-urlencoded.

1. Hinzufügen eines Anforderungstexts

Beim Öffnen des Registerkartenkörpers müssen 2 Parameter hinzugefügt werden:

• 1. Parameter: Nutzername.
  Als Schlüssel des ersten Parameters wird die Nutzername muss hinzugefügt werden.
  Als Wert - tatsächlicher Benutzername, der normalerweise für die Anmeldung am System verwendet wird.

• 2. Parameter: Passwort
  Als Schlüssel des ersten Parameters wird die Passwort muss hinzugefügt werden.
  Als Wert - ein tatsächliches Kennwort, das normalerweise für die Anmeldung am System verwendet wird. Das verschlüsselte Passwort muss jedoch in dieses Feld eingefügt werden. 

Login-Anfrage

Nachdem alle Schritte abgeschlossen und alle notwendigen Parameter hinzugefügt wurden, kann eine Anmeldeanfrage an den Server gesendet werden.

Wenn die Anmeldeanfrage an den Server gesendet wurde, wird eine Antwort vom Server empfangen, die 2 Token enthält (Zugriff + Aktualisierung).

Darüber hinaus ist das HttpOnly-Cookie access_token wird automatisch festgelegt, dass jeder Aufruf an den Server aktiviert werden kann. Das Cookie kann auch im Browser gefunden werden.

Als Alternative zu einem HttpOnly-Cookie wird die Ermächtigung Header kann beim Senden der Anfrage hinzugefügt werden. Um den Autorisierungsheader hinzuzufügen, wird die Ermächtigung Registerkarte muss geöffnet werden. Auf der Registerkarte Autorisierung sollten 2 Schritte ausgeführt werden:

1. das Überbringer Token muss als Autorisierungstyp ausgewählt werden.

2. Das zuvor empfangene Zugriffstoken muss dem Zeichen Feld.

Anforderung zum Aktualisieren von Token

Um beide Token zu aktualisieren (Zugriff + Aktualisieren), wird die Anforderung an den Server mit Endpunkt /tim/api/auth/refresh und die HTTP-Methode POST muss gesendet werden.

Darüber hinaus muss das zuvor abgerufene Aktualisierungstoken dem Text als Parameter hinzugefügt werden.

• Schlüssel- refreshToken

• Wert - Aktualisierungstoken, das während der Anmeldeanforderung empfangen wurde.

In diesem Fall wurde ein neues Paar von Zugriffs- und Aktualisierungstoken empfangen. Im Falle der Verwendung des TIM-Produkts erfolgt die Anforderung der Token-Erneuerung automatisch, wodurch der Benutzer lange Zeit im System authentifiziert bleiben kann.

Abmeldeanforderung

Logout-Anfragen können über die Schaltfläche /tim/api/auth/logout Endpunkt und HTTP-Methode GET.

Wenn sich der Benutzer abmeldet, wird das HttpOnly-Cookie access_token wird gelöscht und der Benutzer kann nicht mehr auf die Ressourcen des Servers zugreifen. Wie im folgenden Screenshot zu sehen ist, wurde das Cookie während der Abmeldeanforderung gelöscht.

Verwenden von JWT in REST-Konnektoren

Konnektoren ermöglichen die Verwendung der REST-API für die Verbindung mit der TIM-API. Die Anforderung muss berechtigt sein, die TIM-API aufzurufen. In diesem Abschnitt wird gezeigt, wie Sie die Authentifizierung in Connectors konfigurieren, um autorisierte Anforderungen auszuführen. Folgende Schritte müssen unternommen werden:

1. Öffnen Sie den Konnektor-Designer, und navigieren Sie zu REST-Konnektoren.

2. Wählen Sie im Abschnitt Authentifizierung die Methode OAuth aus, und geben Sie den entsprechenden Benutzernamen und das Kennwort wie im Anmeldeformular ein.

    

3. Öffnen Sie die OAuth-Header und geben Sie die folgenden Werte in die Parameter ein:

   • oAuthClientId -> -

   • oAuthClientSecret -> -

   • oAuthTokenUrl -> https://${server}/tim/api/auth/login

4. Setzen Sie Werte für alle Parameter auf der Endpunktkonfiguration und ggf. auf der Abfrageparameter Registerkarte.

5. Navigieren Sie zum Testen und führen Sie die Anforderung aus.

Allgemeine Informationen & FAQ

Was sind die Vorteile von JWT?

• Keine Datenbankaufrufe erforderlich: Da JWTs in sich geschlossen sind, alle notwendigen Informationen im Token vorhanden sind und die Speicherung zusätzlicher Daten über ausgegebene Sitzungen nicht erforderlich ist, muss der Server lediglich die Signatur überprüfen. Daher bedeutet es weniger Datenbankabfragen und eine schnellere Antwortzeit. Es sollte auch beachtet werden, dass dieser Vorteil entfällt, wenn die Deny-Liste der Token implementiert wird.

• Zeitbasierte Token: JWTs laufen in bestimmten Intervallen ab, was sie sicherer macht.

• Keine zu verwaltende Sitzung (zustandslos): JWT-Token können in Cookies oder im lokalen Speicher gespeichert werden, anstatt wie bei der traditionellen Erstellung einer Sitzung auf dem Server. Die beste Option ist, sie im httpOnly-Cookie zu speichern.

• Tragbar: Ein einzelnes Token kann mit mehreren Backends verwendet werden (wenn Backends dieselben privaten Schlüssel verwenden).

• Digital signiert: Informationen werden verifiziert und vertrauenswürdig. JWTs sollten mit einem geheimen Schlüssel (mit dem HMAC-Algorithmus) oder einem öffentlichen/privaten Schlüsselpaar mit RSA oder ECDSA signiert werden.

Gebrauchen

JWTs können auf verschiedene Arten verwendet werden:

• Authentication: Wenn sich ein Benutzer erfolgreich mit seinen Anmeldeinformationen anmeldet, wird ein ID-Token zurückgegeben.

• Authorization: Sobald ein Benutzer erfolgreich angemeldet ist, kann eine Anwendung im Namen dieses Benutzers Zugriff auf Routen, Dienste oder Ressourcen (z. B. APIs) anfordern. Dazu muss es in jeder Anforderung ein Zugriffstoken übergeben, das in Form eines JWT vorliegen kann. Single Sign-On (SSO) verwendet JWT aufgrund des geringen Overheads des Formats und seiner Fähigkeit, problemlos über verschiedene Domänen hinweg verwendet zu werden.

• Information Exchange: JWTs sind eine gute Möglichkeit, Informationen sicher zwischen Parteien zu übertragen, da sie signiert werden können, was bedeutet, dass Sie sicher sein können, dass die Absender die sind, für die sie sich ausgeben. Darüber hinaus können Sie anhand der Struktur eines JWT überprüfen, ob der Inhalt nicht manipuliert wurde.

Struktur von JWT

JWT besteht aus 3 Teilen, die durch einen Punkt getrennt sind.

Das payload enthält die Ansprüche. Dies wird als JSON-Zeichenfolge angezeigt, die normalerweise nicht mehr als ein Dutzend Felder enthält, um das JWT kompakt zu halten. Diese Informationen werden normalerweise vom Server verwendet, um zu überprüfen, ob der Benutzer über die Berechtigung zum Ausführen der von ihm angeforderten Aktion verfügt.

Es gibt keine obligatorischen Ansprüche für ein JWT, aber sich überschneidende Standards können Ansprüche obligatorisch machen. Wenn Sie beispielsweise JWT als Bearer-Zugriffstoken verwenden, sind einige der registrierten Ansprüche vorhanden:

1. "iss" (Emittenten-) Forderung

2. "sub"(Betreff-)Anspruch

3. "aud" (Publikums-)Anspruch

4. "exp"(Verfallszeit) Anspruch

5. "nbf" (Nicht vorher) Anspruch

6. "iat" (Ausgestellt bei) Anspruch

7. "jit" (JWT ID) Anspruch

Das Unterschrift stellt sicher, dass das Token nicht geändert wurde. Die Partei, die das JWT erstellt, signiert den Header und die Nutzlast mit einem geheimen Schlüssel, der sowohl dem Aussteller als auch dem Empfänger bekannt ist, oder mit einem privaten Schlüssel, der nur dem Absender bekannt ist. Wenn das Token verwendet wird, überprüft die empfangende Partei, ob der Header und die Nutzlast mit der Signatur übereinstimmen. 

Wie funktioniert JWT?

Wenn sich der Benutzer bei der Authentifizierung erfolgreich mit seinen Anmeldeinformationen anmeldet, wird JWT zurückgegeben. Da Token Anmeldeinformationen sind, muss sehr darauf geachtet werden, Sicherheitsprobleme zu vermeiden. Im Allgemeinen sollten Token nicht länger als erforderlich aufbewahrt werden.

Wann immer der Benutzer auf eine geschützte Route oder Ressource zugreifen möchte, sollte der Benutzeragent das JWT senden, normalerweise in der Authorization -Header mit dem Bearer Schema. Der Inhalt der Kopfzeile sollte wie folgt aussehen:

Dies kann in bestimmten Fällen ein staatenloser Autorisierungsmechanismus sein. Die geschützten Routen des Servers suchen nach einem gültigen JWT im Authorization -Header, und wenn vorhanden, kann der Benutzer auf geschützte Ressourcen zugreifen. Wenn das JWT die erforderlichen Daten enthält, kann die Notwendigkeit, die Datenbank für bestimmte Operationen abzufragen, reduziert werden, obwohl dies möglicherweise nicht immer der Fall ist.

Wenn das Token in der Authorization -Header ist Cross-Origin Resource Sharing (CORS) kein Problem, da es keine Cookies verwendet.

Das folgende Diagramm zeigt das Anmeldeszenario: