Richte eigene OAuth-Anwendungen für Integrationen ein, weise Clients deinem Workspace oder Nutzergruppen zu und steuere Scopes, Tenant-Richtlinien und Branding.
Du kannst mehrere eigene OAuth-Clients für dieselbe Integration verwenden. Lege einen Client für deinen gesamten Workspace fest und weise weitere Clients bestimmten Nutzergruppen zu. So nutzen verschiedene Gruppen dieselbe Integration mit unterschiedlichen OAuth-Clients.
Wenn du einen eigenen OAuth-Client konfigurierst, leitet Langdock neue Authentifizierungsabläufe über die OAuth-Anwendung, die dem jeweiligen Nutzer zugewiesen ist. Der Client für den gesamten Workspace gilt standardmäßig. Gruppen-Clients gelten für Mitglieder der zugewiesenen Gruppen. Das bedeutet:
Dein Branding (eigener Name und eigenes Logo) erscheint auf den Zustimmungsseiten
Deine Tenant-Richtlinien steuern den Nutzerzugriff und die Anforderungen an die Admin-Zustimmung
Deine Rate-Limits gelten für API-Aufrufe, die von deinen Nutzern ausgeführt werden
Deine Nutzergruppen können sich über separate OAuth-Clients authentifizieren
1
OAuth-App beim Anbieter erstellen
Registriere eine neue OAuth-Anwendung im Entwicklerportal deines Anbieters (z. B. Google Cloud Console, Microsoft Azure).Erforderliche Konfiguration:
Kopiere die exakte Redirect-URL aus den Integrationseinstellungen von Langdock
Wähle alle benötigten Scopes aus, die in Langdock für diese Integration angezeigt werden
Client secret (erforderlich für die meisten Integrationen)
Tenant ID (optional, wird nur bei Microsoft-Integrationen angezeigt)
3
In Langdock konfigurieren
Öffne Workspace Einstellungen → Integrationen, wähle die Integration aus und scrolle zu Bring your own OAuth Client.Klicke auf Weiteren OAuth-Client hinzufügen, wenn die Integration einen Langdock-Client enthält. Wenn die Integration deinen eigenen Client erfordert, klicke auf Konfiguriere deinen OAuth-Client, um diese Integration zu nutzen.Kopiere im Konfigurationsdialog die Redirect URL in deine OAuth-Anwendung und prüfe den Abschnitt Scopes. Stelle sicher, dass alle aufgeführten Scopes in deiner OAuth-Anwendung aktiviert sind – fehlende Scopes führen zu einem Fehler wegen unzureichender Berechtigungen. Über die Kopieren-Schaltfläche kannst du alle Scopes auf einmal kopieren.Für Integrationen mit Action-Level-Berechtigungen empfehlen wir, Scopes von aktivierten Aktionen synchronisieren standardmäßig aktiviert zu lassen. Langdock fragt dann die Auth-Scopes sowie die Scopes an, die für aktivierte oder geteilte Aktionen erforderlich sind. So bleiben die angefragten Scopes auf die Aktionen abgestimmt, die dein Workspace nutzen kann. Mehr dazu unter Action-Level-Scopes verwalten.Füge optional einen aussagekräftigen Client Name hinzu. Wähle unter Zugriff die Option Gesamter Workspace oder Gruppen. Trage deine Client ID und dein Client secret ein (und bei Microsoft-Integrationen zusätzlich die Tenant ID, falls abgefragt). Wenn die Integration zusätzliche Verbindungsfelder zeigt, setze sie unter OAuth-Verbindungsdetails. Klicke danach auf Speichern und bestätige die Änderung.Wähle den gespeicherten Client aus der Client-Liste aus und bestätige den Wechsel, um ihn zu aktivieren.
Sobald der Client aktiv ist, verwenden neue Verbindungen von Nutzern mit Zugriff auf diesen Client ihn sofort und funktionieren nur, wenn die Zugangsdaten gültig sind. Bestehende Verbindungen bleiben mit dem Client verknüpft, mit dem sie erstellt wurden.
4
Authentifizierung testen
Lass einen Nutzer sein Konto verbinden und prüfe:
Auf der Zustimmungsseite wird dein Client angezeigt
Die benötigten Scopes werden erteilt
Der Datenzugriff über die Actions funktioniert wie erwartet
Verwende Gruppenzugriff, wenn verschiedene Teile deiner Organisation separate OAuth-Anwendungen für dieselbe Integration benötigen. Weise zum Beispiel einer Tochtergesellschaft mit eigenem Microsoft Entra Tenant einen Client zu oder verwende einen separaten Client, wenn eine Abteilung andere freigegebene Scopes benötigt. Der Client für deinen gesamten Workspace bleibt der Standard für alle Nutzer, die keinem Gruppen-Client zugewiesen sind.
1
Weiteren eigenen Client hinzufügen
Klicke auf Weiteren OAuth-Client hinzufügen. Gib dem Client optional einen aussagekräftigen Namen, damit du ihn in der Client-Liste erkennst.
2
Client-Zugriff verwalten
Wähle im Abschnitt Zugriff die Option Gruppen aus. Klicke dann auf Verwalten, um die Nutzergruppe auszuwählen, die diesen Client verwenden soll.
3
Zugangsdaten hinzufügen
Trage Client ID, Client secret und alle vom Anbieter benötigten Felder ein. Klicke auf Speichern und bestätige die Änderung. Wähle den gespeicherten Client aus der Client-Liste aus und bestätige den Wechsel, um ihn zu aktivieren.
Lass einen Client für den gesamten Workspace aktiv, wenn Nutzer ohne Gruppen-Client eine Verbindung herstellen müssen. Ein Nutzer kann nicht zu Gruppen gehören, denen zwei aktive OAuth-Clients für dieselbe Integration zugewiesen sind.
Der Konfigurationsdialog enthält die folgenden Abschnitte:
Redirect URL
Scopes
Credentials
Ein schreibgeschütztes Feld, das die Redirect-URL anzeigt, die deine OAuth-Anwendung verwenden muss. Klicke auf die Kopierschaltfläche, um sie exakt zu übernehmen. Das URL-Format lautet:
Die Redirect-URL muss exakt übereinstimmen. Jede Abweichung führt zu redirect_uri_mismatch-Fehlern. Die genaue Domain hängt von deinem Langdock-Deployment ab – kopiere die Redirect-URL daher immer aus dem Dialog, anstatt sie manuell zusammenzubauen.
Zeigt die OAuth-Scopes an, die für die einwandfreie Funktion der Integration erforderlich sind. Jira benötigt beispielsweise Scopes wie read:jira-work, write:jira-work, read:jira-user, offline_access und manage:jira-configuration.
Kopieren: Kopiert alle Scopes in die Zwischenablage, sodass du sie in die Konfiguration deiner OAuth-Anwendung einfügen kannst.
Bearbeiten: Wechselt in den Bearbeitungsmodus, in dem du die Scopes in einem Textfeld anpassen kannst (nur für fortgeschrittene Anwendungsfälle).
Auf Standard-Scopes zurücksetzen: Stellt die ursprüngliche Scope-Liste wieder her, falls du sie verändert hast.
Für Integrationen mit Action-Level-Berechtigungen solltest du Scopes von aktivierten Aktionen synchronisieren aktiviert lassen, sofern du nicht bewusst eine feste Scope-Liste selbst verwalten möchtest. Das ist die empfohlene Standardeinstellung, weil Langdock die OAuth-Scopes mit aktivierten und geteilten Aktionen synchron halten kann.
Alle aufgeführten Scopes müssen in deiner OAuth-Anwendung aktiviert sein. Fehlende Scopes führen zu insufficient_scope-Fehlern, wenn Nutzer eine Verbindung herstellen möchten.
Gib die Zugangsdaten deiner OAuth-Anwendung ein:
Client Name (optional): Ein aussagekräftiger Name, mit dem du den Client in Langdock erkennst
Client ID (erforderlich): Öffentliche Kennung deiner Anwendung
Client secret (erforderlich für die meisten Integrationen): Privater Schlüssel deiner Anwendung, verschlüsselt gespeichert
Tenant ID (nur bei Microsoft-Integrationen, optional): Die Kennung deines Azure-AD-Tenants
OAuth-Verbindungsdetails (wenn angezeigt): zusätzliche Felder für diesen Client, jeweils mit Optional gekennzeichnet
Manche Integrationen fragen zusätzliche Verbindungsfelder ab, zum Beispiel eine Instanz-URL, eine Subdomain oder eine Store Domain. Speichere diese Werte als Workspace-Standard, damit Mitglieder die Abfrage beim Verbinden überspringen.
Auf der Karte Langdock-Client klickst du auf Konfigurieren, wenn diese Felder erscheinen. In Dedicated Deployments heißt die Karte Globaler Client.
Bei einem eigenen Client erscheinen dieselben Felder im Konfigurationsdialog und gelten nur für diesen Client. Ein Standard vom Langdock-Client gilt nicht für eine Verbindung über einen eigenen Client.
Lass ein Feld leer, wenn Mitglieder den Wert beim Verbinden eingeben sollen. Trage einen Wert ein, um den Standard zu setzen, zum Beispiel https://acme.service-now.com. Jedes Feld ist mit Optional gekennzeichnet.
Wenn jedes zusätzliche Feld bereits einen gespeicherten Wert hat, gehen Mitglieder direkt zur Anmeldung. Ist ein Feld leer, geben sie es weiterhin ein. Workspace-Admins, die diesen Dialog sehen, bekommen ein Banner mit einem Link zurück zu den Integrationseinstellungen.
Der Dialogtitel, die Feldbezeichnung und der Platzhalter bleiben auf Englisch. Das Banner und die Schaltfläche Weiter zu ServiceNow folgen der App-Sprache.Die Microsoft-Tenant ID bleibt ein separates Feld unter Credentials. Bestehende Verbindungen behalten ihre gespeicherten Werte. Neue Verbindungen und die erneute Autorisierung nutzen die aktuellen Standards.
Jede Karte zeigt den Client-Namen, die Zugriffsart, den Scope-Modus und den Aktivierungsstatus.
Wähle die Karte eines inaktiven Clients aus, um ihn zu aktivieren.
Wähle die Karte eines aktiven eigenen Clients aus, um ihn zu deaktivieren.
Klicke auf das Einstellungssymbol, um den Client zu bearbeiten.
Öffne die Client-Einstellungen und klicke auf OAuth-Client Konfiguration löschen, um den Client zu entfernen.
Wähle Langdock-Client, damit neue Verbindungen den verwalteten Client verwenden. Dadurch werden alle eigenen Clients deaktiviert.
Du kannst mehrere Gruppen-Clients aktiv lassen, wenn sich ihre Mitglieder nicht überschneiden. Für eine Integration kann nur ein Client für den gesamten Workspace aktiv sein.
Wenn du einen Client deaktivierst, verwenden neue Verbindungen ihn nicht mehr. Bestehende Verbindungen bleiben mit ihrem ausgewählten Client verknüpft. Wenn du einen Client löschst, können vorhandene Access Tokens bis zu einem Authentifizierungsfehler weiter funktionieren. Nutzer müssen sich dann mit einem geeigneten aktiven Client neu autorisieren.
Integrationen, die einen eigenen OAuth-Client erfordern
Einige unserer Integrationen können nur verwendet werden, wenn du einen eigenen OAuth-Client bereitstellst. Details zum Verbinden dieser Integrationen mit Langdock sind in diesem Abschnitt beschrieben.
UiPath hat keinen von Langdock verwalteten OAuth-Client. Externe Applications werden pro Automation-Cloud-Organisation registriert. Deshalb muss ein UiPath-Admin in deiner Organisation eine Confidential Application anlegen, bevor User Orchestrator verbinden können.
Anzeigen wie du einen UiPath-OAuth-Client konfigurierst
In UiPath
Öffne unter der Organisation Admin → External applications → OAuth apps.
Klicke auf Add application und wähle Confidential application.
Unter Orchestrator vergebe die in Langdock angezeigten Scopes nur unter User Scope(s). Lass Application Scope(s) leer.
Klicke auf Konfiguriere deinen OAuth-Client, um diese Integration zu nutzen.
Füge Application ID und App Secret ein, speichere, und aktiviere den Client.
Erforderliche Input-Felder für die Authentifizierung
UiPath Cloud URL (Organisation und Tenant)
Speichere die UiPath Cloud URL als Workspace-Standard unter OAuth-Verbindungsdetails, zum Beispiel https://cloud.uipath.com/acme/DefaultTenant/orchestrator_/. Wenn du das Feld leer lässt, fügt das verbindende Mitglied eine solche URL ein oder gibt org / org/tenant ein. Langdock führt einen user-delegated OAuth-Flow mit den Orchestrator-Rechten dieses Users aus.Vollständige Guides
Werden selbst gehostete oder cloudbasierte Konten unterstützt?
Nur UiPath Automation Cloud. Automation Suite und andere Self-Hosted-Hosts werden nicht unterstützt.
Warum gibt es keinen von Langdock verwalteten OAuth-Client?
Externe OAuth-Apps werden pro UiPath-Organisation registriert. Ein Client aus einer Organisation deckt nicht alle Langdock-Kunden ab. Jede Organisation legt deshalb ihre eigene Confidential Application an.
Sind besondere Berechtigungen oder Rollen erforderlich?
Ja.
Ein UiPath-Admin legt die External Application an.
Scopes liegen unter User Scope(s) für Orchestrator, nicht unter Application Scope(s).
Verbindende User brauchen Orchestrator-Zugriff auf die Folders und Processes, die sie in Langdock nutzen.
Was ist mit UiPath Automation Hub?
Separate Integration. Sie nutzt ein Open-API-Token (API Key), nicht diesen OAuth-Client.Token-Setup und Least-Privilege-Hinweise stehen im UiPath Setup-Guide.
Anzeigen wie du einen ServiceNow-OAuth-Client konfigurierst
Um diese Integration für deinen Arbeitsbereich zu aktivieren, muss ein ServiceNow Systemadministrator einen OAuth-Client als Application Registry in ServiceNow erstellen und dieser Dokumentation folgen. Erforderliche Input-Felder für die Authentifizierung
ServiceNow-Subdomain angeben
Speichere die ServiceNow-Subdomain als Workspace-Standard unter OAuth-Verbindungsdetails. Wenn du das Feld leer lässt, geben Mitglieder sie beim Verbinden ein.
Werden selbst gehostete oder cloudbasierte Konten unterstützt?
Derzeit werden nur cloudbasierte Konten unterstützt.
Ist ein bezahlter ServiceNow-Plan erforderlich?
Ein bezahltes ServiceNow-Konto ist erforderlich, um eine Application Registry zu erstellen. Mehr Informationen hier.
Sind besondere Berechtigungen oder Rollen erforderlich?
Ja. Für die Verbindung per OAuth sollte dein Systemadministrator die richtige Konfiguration innerhalb deiner Instanz einrichten, damit sich jeder Nutzer über eine OAuth-Verbindung verbinden kann. Beispielsweise benötigen alle Nutzer die Rolle oauth_user, um sich verbinden zu können. Mehr Informationen hier.
Gibt es Nutzungsbegrenzungen?
Ja. ServiceNow setzt Begrenzungen ein, um übermäßige API-Nutzung zu verhindern. Administratoren können Regeln konfigurieren, die die Anzahl eingehender REST-API-Anfragen pro Stunde beschränken. Mehr Informationen hier.
Shopify Admin hat keine von Langdock verwaltete OAuth App. Ein Workspace Admin erstellt eine App im Shopify Dev Dashboard und trägt Client ID und Client Secret in Langdock ein. Connections nutzen Berechtigungen auf Anwendungsebene: Langdock handelt mit den Admin API Scopes der App, nicht mit der persönlichen Shopify Rolle der Person, die installiert hat.
Anzeigen wie du einen Shopify Admin OAuth Client konfigurierst
Store Domain (eine Custom Domain, eine *.myshopify.com Domain oder der Store Handle)
Speichere die Store Domain als Workspace-Standard unter OAuth-Verbindungsdetails, zum Beispiel acme-store.myshopify.com. Wenn du das Feld leer lässt, geben Mitglieder sie beim Verbinden ein.Aus Langdock in die Shopify App kopieren
Redirect URL aus dem Shopify Admin OAuth Client Dialog
Die dort angezeigten Admin API Scopes (oder die vollständige Liste im Einrichtungsguide)
Die Konfiguration eines eigenen OAuth-Clients für Snowflake gibt dir Kontrolle über Authentifizierungsrichtlinien, Token-Gültigkeitszeiträume und IP-Allowlisting in deiner Snowflake-Umgebung.
Anzeigen wie du einen Snowflake-OAuth-Client konfigurierst
Erforderliche Informationen:
OAuth Redirect URL: Kopiere diese aus den Snowflake-Integrationseinstellungen in Langdock
Client-ID: Wird von Snowflake nach Erstellung der Security Integration generiert
Client-Secret: Wird von Snowflake nach Erstellung der Security Integration generiert
Authorization URL: Der Autorisierungs-Endpunkt deines Snowflake-Kontos
Die Redirect URL aus Langdock muss in Snowflake bereitgestellt werden, während Client-ID, Client-Secret und Authorization URL aus Snowflake in die Langdock-Integrationseinstellungen eingetragen werden müssen.
Wenn dein Snowflake-Konto Netzwerkrichtlinien oder IP-Allowlisting aktiviert hat, musst du möglicherweise die statische IP-Adresse von Langdock freigeben, um Verbindungen zu ermöglichen. Siehe Statische IP-Konfiguration für Details.
Ersetze <integration_name> durch einen aussagekräftigen Namen und <your_redirect_uri> durch die OAuth Redirect URL aus Schritt 1.
Führe die Abfrage aus, um deine neue Security Integration in Snowflake zu erstellen. Hinweis: Passe den Wert von OAUTH_REFRESH_TOKEN_VALIDITY entsprechend deiner Sicherheitsrichtlinien an.
3
Client-ID und Client-Secret abrufen
Anzeigen wie du die Client-ID und Client-Secret aus Snowflake abrufen kannst
Führe im selben Arbeitsbereich folgende Abfrage aus:
