OAuth2.0 Konfiguration und technische Details

In diesem Artikel werden wir uns mit den technischen Details befassen, wie Tulip OAuth für die Connector-Authentifizierung implementiert. OAuth ist leistungsfähig, aber es bringt auch eine gewisse Komplexität mit sich. Dieser Leitfaden soll alle technischen Fragen dazu beantworten, was Tulip unterstützt und wie es integriert ist.

Hinweis: Der Ablauf der Client Credentials unterscheidet sich etwas vom Ablauf des Autorisierungscodes. Die Schritte 1 und 2 sind für den Client Credentials Flow nicht relevant.

Tulip Autorisierungscode-Fluss

:::(Warning) (On-Prem Services) Die Endpunkte Authorize und Token müssen für die Cloud zugänglich sein, damit Tulip die Authentifizierung für Konnektoren :: ausführen kann:

Tulip initiiert den Authentifizierungsprozess, wenn ein Connector getestet oder eine Connector-Funktion innerhalb einer Anwendung ausgeführt wird.

1. Umleitung zum Autorisierungsserver:

Die Tulip-Anwendung leitet den Benutzer zum Autorisierungsserver (AS) um, zusammen mit spezifischen Parametern, einschließlich response_type (eingestellt auf "code" für Authorization Code Flow), client_id (zugewiesen in der Connector UI), redirect_uri (vordefiniert von Tulip), scope und audience (eingestellt in der UI), und state (eine zufällige Zeichenkette zum Schutz gegen Cross-Site Request Forgery Angriffe).

Beispiel:GET /authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=SCOPE&audience=AUDIENCE&state=STATE

2. Der Benutzer erteilt seine Zustimmung:

Der Autorisierungsserver authentifiziert den Benutzer und zeigt ihm einen Zustimmungsbildschirm an. Der Benutzer kann die angeforderten Berechtigungen überprüfen und entscheiden, ob er den Zugriff auf die Drittanbieteranwendung gewährt oder verweigert.

:::(Warning) (Hinweis) Innerhalb der Konfiguration eines Give Connectors können Sie mit dem Steuerelement "Skip user consent prompt" das Prompt-Attribut auf der Autorisierungsanfrage steuern. Wenn dieses Steuerelement deaktiviert ist, wird der Wert consent verwendet, wenn es aktiviert ist, wird login verwendet.

Wenn zusätzliche Werte für das Prompt-Attribut benötigt werden, wenden Sie sich an support@tulip.co, und wir werden weitere Optionen für diese Eigenschaft aktivieren. :::

3. Autorisierungscode:

Wenn der Benutzer sein Einverständnis gibt, erzeugt der Autorisierungsserver einen Autorisierungscode und leitet den Benutzer zusammen mit dem Autorisierungscode zurück zu Tulip. Der State-Parameter ist ebenfalls enthalten, damit der Client die Integrität der Antwort überprüfen kann. Dieser Zustandsparameter muss mit dem in Schritt 1 übergebenen Zustandsparameter übereinstimmen.

Beispiel für die Weiterleitung an die Redirect-URI des Kunden:

REDIRECT_URI?code=AUTHORIZATION_CODE&state=STATE

4. Token-Anforderung:

Der Client verfügt nun über den Autorisierungscode und verwendet ihn, um eine sichere Server-zu-Server-Anfrage an den Token-Endpunkt des Autorisierungsservers zu stellen. Der Client gibt den grant_type (auf "authorization_code" gesetzt), client_id, client_secret (ein Geheimnis, das nur dem Client und dem Autorisierungsserver bekannt ist), redirect_uri und den Autorisierungscode an.

Beispiel einer Token-Anforderung:

grant\_type=authorization\_code&code=AUTHORIZATION\_CODE&redirect\_uri=REDIRECT\_URI&client\_id=CLIENT\_ID&client\_secret=CLIENT\_SECRET ```


### 5. Access Token Antwort:


Wenn der Autorisierungscode gültig ist, antwortet der Autorisierungsserver mit einem Zugriffstoken und optional mit einem Refresh-Token. Das Zugriffstoken wird vom Client verwendet, um sich zu authentifizieren, wenn er im Namen des Benutzers Anfragen an die geschützte API stellt.


Beispiel Token-Antwort:


`{ "access_token": "ACCESS_TOKEN", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "REFRESH_TOKEN", "scope": "SCOPE" }`


### 6. Zugriff auf den Ressourcenserver:


Tulip kann nun das erhaltene Zugriffstoken verwenden, um im Namen des Benutzers autorisierte Anfragen an den Ressourcenserver (API) zu stellen. Das Zugriffstoken ist normalerweise im Authorization-Header der HTTP-Anfrage enthalten.


Beispiel API-Anfrage:`GET /api/resource Autorisierung: Überbringer ACCESS_TOKEN`


## Verwaltung des Token-Ablaufs mit Refresh-Tokens


Autorisierungsserver legen in der Regel Ablaufdaten für Token fest, um den Zugriff zu regeln, wobei die Ablauffenster je nach dem angeschlossenen System variieren. Kurzlebige Token stellen jedoch eine Herausforderung dar, da die ständige Benutzerauthentifizierung das Benutzererlebnis in Tulip-Anwendungen stört.


Um dieses Problem zu lösen, unterstützt OAuth Refresh-Tokens. Sie sind zwar optional, aber sehr empfehlenswert, da sie das Benutzererlebnis optimieren, indem sie Tulip die nahtlose Aktualisierung von Token ermöglichen, ohne dass manuelle Eingaben von Bedienern erforderlich sind.


### Wie Tulip die Token-Aktualisierung verwaltet


Wenn Tulip feststellt, dass ein Zugangstoken abgelaufen ist, versucht sie automatisch, das zugehörige Refresh-Token zu verwenden, um ein neues Token zu erhalten. Das Hauptziel ist es, die Neuauthentifizierung des Benutzers zu minimieren. Die folgenden Schritte umreißen die von Tulip ausgeführte Logik:


![Token Refresh Flow](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/image%28399%29.png)


1. **Erkennung des Ablaufs:**
2. Tulip identifiziert ein abgelaufenes Token anhand des Attributs `expires_in`, das in [Schritt 5](/r230/docs/oauth20-configuration-and-technical-details#5-access-token-response) des Authentifizierungsflusses empfangen wurde.
3. **Token Flow-Versuch:**
4. Tulip initiiert den Token-Flow unter Verwendung des Grant-Typs `refresh_token` und ersetzt damit den Grant-Typ `authorization_code`, der im anfänglichen Authentifizierungsfluss verwendet wurde.
5. **Token-Validierung:**
6. Wenn ein neues Token erhalten wird, speichert Tulip es und führt die vom Benutzer angeforderte Verbindungsfunktion aus.


	* Bei Erfolg werden die Daten an die Tulip-App-Laufzeit geliefert.
	* Wenn das neue Token mit einem OAuth-Fehler fehlschlägt, wiederholt Tulip den Prozess bis zu 5 Mal und kehrt jedes Mal zu Schritt 1 zurück.
	* Wenn das neue Token mit einem anderen Fehler fehlschlägt, wird ein Fehler in der Player-Laufzeitumgebung angezeigt.
7. **Behandlung von fehlenden Token:**
8. Wenn kein neues Token zur Verfügung gestellt wird, fordert Tulip den Benutzer im Player auf, sich zu authentifizieren, wobei der gesamte Authentifizierungsprozess eingeleitet wird.
9. Nach Abschluss wird die Konnektorfunktion ausgeführt und die Daten werden zurückgegeben.


Durch die Implementierung von Refresh-Tokens sorgt Tulip für eine reibungslosere Benutzererfahrung, indem es das Ablaufen und die Erneuerung von Token intelligent verwaltet und so Unterbrechungen im Arbeitsablauf minimiert.


## Weitere Lektüre


* [Einführung in Tulip Connector Hosts](/r230/docs/introduction-to-tulip-connector-hosts-1)
* [Connector-Snapshotting](/r230/docs/connector-snapshotting)
* [OAuth2.0 Erläutert](/r230/docs/oauth20-explained)