Was ist OAuth2.0?

Erforschung von OAuth2.0

Willkommen zu einer Erkundung von OAuth2.0, einem leistungsstarken, aber oft missverstandenen Authentifizierungsprotokoll im Tulip-Umfeld. In diesem Artikel werden wir die Grundlagen enträtseln, Sie durch die von Tulip unterstützten Authentifizierungsabläufe führen, die Konfiguration Ihres ersten Connectors entmystifizieren und schnelle Tipps für einen reibungslosen Start geben.

OAuth2.0 kann kompliziert sein, und um die Dinge kurz zu halten, haben wir einige detaillierte technische Aspekte in diesem Artikel ausgelassen. Wenn Sie einen tieferen Einblick in Tulips Umgang mit Refresh-Tokens, Scope- und Audience-Management und benutzerdefinierten Connector-Konfigurationen haben möchten, empfehlen wir Ihnen diesen ausführlichen technischen OAuth2.0-Leitfaden.

Enthüllung der Grundlagen

Bevor Sie sich in die Einzelheiten vertiefen, empfehlen wir Ihnen, sich mit Environments vertraut zu machen und sich einen Überblick über Connector Hosts und ihre Funktionen zu verschaffen.

OAuth2.0 dient als Mechanismus für Tulip (den Client), um seine Identität mit Ihren Geschäftssystemen herzustellen. Der Zugang wird über einen Handshake gewährt, und Tulip unterstützt in erster Linie den Authorization Code Flow, den gängigsten OAuth-Flow. Hier ist ein kurzer Überblick über den Ablauf dieses Flusses:

1. Der Benutzer initiiert den Flow, indem er auf die Schaltfläche Test klickt, bevor er einen Connector speichert.
2. Tulip kommuniziert mit dem Autorisierungsserver Ihres OAuth-Anbieters und teilt spezifische Parameter wie Client-Identität, Bereiche (worauf Sie zugreifen wollen) und andere relevante Details mit.
3. Der Autorisierungsserver fordert den Benutzer auf, den Zugriff zu gewähren, wie unten dargestellt:

1. Wenn der Benutzer zustimmt, generiert der Autorisierungsserver einen Autorisierungscode und schließt das Authentifizierungsfenster ab.
2. Mit dem Autorisierungscode fordert Tulip sicher ein Token an, indem sie sich an den Token-Endpunkt wendet und den Autorisierungscode, die Client-ID, das Client-Geheimnis und zusätzliche Eigenschaften angibt.
3. Nach der Validierung des Autorisierungscodes antwortet der Server mit einem Token und optional mit einem Refresh-Token. Dieses Token dient für benutzerautorisierte Anfragen.
4. Tulip kann nun Anfragen im Namen von Benutzern ausführen, mit dem bereitgestellten Token für die Autorisierung.

OAuth konfigurieren

Beispielkonfiguration

Authentifizierungsarten

Tulip unterstützt zwei OAuth2.0-Authentifizierungstypen: Admin OAuth und Operator OAuth. Der Hauptunterschied liegt in der Art und Weise, wie die Anmeldedaten zwischen den Benutzern geteilt werden.

:::(Info) (Hinweis) In älteren Tulip-Versionen wurde OAuth2.0 (Service Account) als OAuth2 (Admin) und OAuth2.0 (User Credentials) als OAuth2 (Operator) bezeichnet. :::

• OAuth2.0 (Dienstkonto): Verwendet Anmeldeinformationen, die während des Konnektortests für alle Benutzer im Tulip Player bereitgestellt werden. Ideal für gemeinsam genutzte Anmeldedaten in Ihrer Organisation. Eine Neuauthentifizierung des Administrators ist erforderlich, wenn die Anmeldedaten ablaufen.
• OAuth2.0 (Benutzeranmeldeinformationen): Segmentiert die Authentifizierung basierend auf dem im Tulip Player angemeldeten Benutzer. Wenn ein Benutzer sich nicht authentifiziert hat oder die Authentifizierung abläuft, durchläuft der Benutzer den OAuth-Fluss innerhalb des Tulip Players.

Autorisierungscode-URL

Dies ist die URL, die Tulip in Schritt 2 des Authentifizierungscodeflusses kontaktiert. Sie ist in der API-Dokumentation Ihres OAuth-Anbieters zu finden und endet normalerweise auf /auth oder /authorize.

Zugriffstoken-URL

Nach der Antwort des Autorisierungsservers wird eine Anfrage an die Access Token URL gestellt, um ein Token für die Authentifizierung zu erhalten. Sie endet in der Regel auf /token.

Client-ID und Client-Geheimnis

Die Client-ID wird von der Benutzeroberfläche Ihres OAuth-Providers generiert und zusammen mit der ersten Anfrage nach einem Authentifizierungscode übergeben. Die Client ID und das Client Secret werden bei allen Token-Anforderungen mitgegeben.

Zielgruppe und Umfang

Audience gibt die spezifischen Assets an, auf die Ihr Benutzer zugreifen möchte, während Scope die gewünschten Aktionen für diese Assets definiert. Beide Angaben werden bei der Anforderung des Autorisierungscodes in Schritt 2 übermittelt.

Zusätzliche Optionen

• Token-Anforderungsdaten als {{Glossar.JSON}} senden: Ändert den Kodierungstyp für die an die Token-URL gesendete Anforderung. Aktiviert, wenn dies für bestimmte Integrationen erforderlich ist.
• Authentifizierungs-Header für Aktualisierungsanforderung senden: Fügt einen zusätzlichen Header zu Aktualisierungsanfragen hinzu, wenn aktiviert.
• Aufforderung zur Benutzerzustimmung überspringen: Steuert das Prompt-Attribut der Authentifizierungscode-Anforderung. Deaktiviert setzt es auf Zustimmung, während aktiviert es auf Anmeldung setzt und dem OAuth-Anbieter die Entscheidung überlässt, welchen Anmeldebildschirm er anzeigt.

:::(Warning) (Hinweis) Bei einigen Integrationen können Sie das Prompt-Attribut ausschließen oder auf none setzen. Wenden Sie sich für weitere Funktionen an support@tulip.co. :::

Tiefer gehen

Möchten Sie weitere Einblicke erhalten? Schauen Sie sich diese Artikel an:

• OAuth2.0 Konfiguration und technische Details
• So führen Sie eine Connector-Funktion in mehreren Umgebungen aus