OAuth2.0 Konfiguration und technische Details

Aktualisiert am 23 Jan 2025
4 Minuten zu lesen
Mitwirkende

Drucken
Teilen
Twitter
Linkedin
Facebook
Email

Artikel-Zusammenfassung

Fanden Sie diese Zusammenfassung hilfreich?

Vielen Dank für Ihr Feedback

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-Ablauf

On-Prem Services

The Authorize and Token endpoints must be accessible to the cloud for Tulip to execute authentication for connectors

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 den Autorisierungscodefluss), 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.

:::(Warnung) (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 Sie zusätzliche Werte für das Prompt-Attribut benötigen, wenden Sie sich bitte 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"}`


:::(Warning) (Services Not Using `expires_in`)

:::


### 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 wird normalerweise in den Authorization-Header der HTTP-Anfrage aufgenommen.


Beispiel für eine API-Anfrage`: GET /api/resourceAuthorization: Bearer ACCESS_TOKEN`


## Verwaltung des Token-Ablaufs mit Refresh-Tokens


Autorisierungsserver legen in der Regel Verfallsdaten für Token fest, um den Zugriff zu regeln, wobei die Verfallszeitfenster je nach angeschlossenem 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 seines `expires_in-Attributs`, das in [Schritt 5](/r230/docs/oauth20-configuration-and-technical-details#5-access-token-response) des Authentifizierungsflusses empfangen wurde.


:::(Warning) (Services Not Using `expires_in`)

:::


1. **Token Flow-Versuch:**
2. Tulip initiiert den Token-Flow unter Verwendung des Grant-Typs `refresh_token` und ersetzt damit den Grant-Typ, der im anfänglichen Authentifizierungs-Flow verwendet wurde.
3. **Token-Validierung:**
4. 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.
5. **Behandlung von fehlenden Token:**
6. 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.
7. 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 den Ablauf 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)

War dieser Artikel hilfreich?

Inhaltsverzeichnis

Tulip Autorisierungscode-Ablauf