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 den gesamten Workspace fest, biete Clients mit Nutzerauswahl an, die Mitglieder vor dem Verbinden selbst wählen, oder weise Clients bestimmten Nutzergruppen zu.
Wenn du einen eigenen OAuth-Client konfigurierst, leitet Langdock neue Authentifizierungsabläufe über deine OAuth-Anwendung statt über den Standard-Client von Langdock. Der Client für den gesamten Workspace gilt standardmäßig. Ein Gruppen-Client gilt für die Mitglieder seiner Gruppen. Nutzerauswahl gibt es bei OAuth-Integrationen, auch bei integrierten Integrationen. Bei MCP-Servern, bei OAuth 2.0 (dynamische Client-Registrierung) und bei OAuth 2.0 (CIMD) gibt es sie nicht. Ist ein Client mit Nutzerauswahl aktiv, wählen Mitglieder vor dem Verbinden selbst einen Client. Diese Auswahl hat Vorrang vor dem Workspace-Client und vor Gruppen-Clients. 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 Name hinzu. Wähle unter Zugriff die Option Gesamter Workspace, Nutzerauswahl 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, wendet Langdock einen Workspace- oder Gruppen-Client automatisch an, solange kein Client mit Nutzerauswahl aktiv ist. Einen Client mit Nutzerauswahl verwendet Langdock nur, wenn ein Mitglied ihn auswählt. Die Verbindung funktioniert nur mit gültigen Zugangsdaten. 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. Wenn kein Client mit Nutzerauswahl aktiv ist, bleibt der Client für den gesamten Workspace der Standard für alle, die keinem Gruppen-Client zugeordnet sind. Ist ein Client mit Nutzerauswahl aktiv, wählen Mitglieder vor dem Verbinden zwischen den aktiven Clients mit Nutzerauswahl, dem Workspace-Client und den Gruppen-Clients ihrer Gruppen.
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:
Name (optional): Ein aussagekräftiger Name, mit dem du den Client in Langdock erkennst
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 Clients mit Nutzerauswahl zusammen mit einem Workspace-Client und mit Gruppen-Clients aktiv lassen, deren Mitglieder sich 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. Die erneute Autorisierung behält den Client der Verbindung, solange er noch existiert. Ist der Client gelöscht und Nutzerauswahl aktiv, bietet die erneute Autorisierung keinen neuen Client an. Der Nutzer erstellt dann eine neue Verbindung. Ist keine Nutzerauswahl aktiv, nutzt die erneute Autorisierung denselben automatischen Gruppen- oder Workspace-Client wie eine neue Verbindung.
Du kannst einen eigenen Miro-OAuth-Client einrichten, wenn du Branding, Tenant-Richtlinien oder Rate-Limits selbst steuern willst. Zeigen die Miro-Integrationseinstellungen OAuth-Client erforderlich, hat dein Deployment noch keinen verwalteten Client. Nutzer können sich erst verbinden, wenn du einen hinzufügst.
Anzeigen wie du einen Miro-OAuth-Client konfigurierst
Miro gibt den Refresh Token, den Langdock für die automatische Token-Aktualisierung benötigt, nur zurück, wenn Expire user authorization token aktiviert ist. Nach dem Erstellen der App kannst du diese Einstellung nicht mehr ändern. Hast du die App bereits ohne die Option erstellt, schlägt das Erstellen einer Verbindung mit dem Fehler Refresh token not found fehl. Erstelle eine neue Miro-App mit aktivierter Option und ersetze Client ID und Client secret in Langdock.
1
App in Miro erstellen
Zum Erstellen von Apps benötigst du ein Developer team in Miro. Melde dich bei Miro an, klicke auf deinen Avatar und wähle Settings. Öffne den Tab Your apps und klicke auf + Create new app.Gib einen App-Namen ein, wähle dein Developer team aus und aktiviere die Checkbox Expire user authorization token. Klicke auf Create app.
2
App mit Langdock verbinden
Trage die Redirect URL aus den Miro-Integrationseinstellungen in Langdock als Redirect URI in deiner Miro-App ein und aktiviere dort jede Berechtigung, die im Abschnitt Scopes aufgeführt ist. Miro verwendet die in der App konfigurierten Berechtigungen und fragt sie nicht bei der Autorisierung an.Trage anschließend Client ID und Client secret aus deiner Miro-App in Langdock ein, wie unter So funktioniert ein eigener OAuth-Client beschrieben.
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:
Snowflake OAuth arbeitet mit Rollen, nicht mit Scopes. Lass Scopes leer, damit jeder verbindende User seine Standardrolle in Snowflake erhält. Trägst du eine Session-Rolle wie session:role:SYSADMIN ein, authentifiziert sich jeder User gegen diese Rolle. Wer sie in Snowflake nicht hat, kann keine Verbindung herstellen.
6
Verbindung testen
Anzeigen wie du eine Verbindung zu deiner Snowflake-Integration hinzufügst
Klicke in deiner Snowflake-Integration auf Add Connection.
Du solltest zum Snowflake-Autorisierungsbildschirm weitergeleitet werden
Melde dich bei deinem Snowflake-Konto an
Du hast deine eigene OAuth Snowflake-Integration erfolgreich eingerichtet!
War diese Seite hilfreich?
Assistant
Responses are generated using AI and may contain mistakes.
