> ## Documentation Index
> Fetch the complete documentation index at: https://docs.langdock.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Bring Your Own OAuth Client

> Richte deine eigene OAuth-Anwendung für Integrationen ein, um Zugriffsrechte zu steuern, zusätzliche Integrationen zu ermöglichen oder den Standard-OAuth-Client von Langdock durch deine eigene Konfiguration zu ersetzen.

<Info>
  Eigene OAuth-Clients gelten arbeitsbereichsweit für die jeweilige Integration. Alle neuen Verbindungen verwenden nach der Einrichtung deine OAuth-Anwendung.
</Info>

## So funktioniert ein eigener OAuth-Client

Wenn du einen eigenen OAuth-Client konfigurierst, leitet Langdock alle Authentifizierungsabläufe über deine OAuth-Anwendung statt über den Standard-Client von Langdock. 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

<Steps>
  <Step title="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
    * Konfiguriere ggf. tenant-spezifische Einstellungen (Admin-Zustimmung, Freigabelisten)
  </Step>

  <Step title="Zugangsdaten sammeln">
    Notiere dir Folgendes aus deiner OAuth-Anwendung:

    * **Client-ID** (immer erforderlich)
    * **Client-Secret** (erforderlich für die meisten Integrationen)
    * **Tenant-ID** (optional, wird nur bei Microsoft-Integrationen angezeigt)
  </Step>

  <Step title="In Langdock konfigurieren">
    Navigiere zu **Workspace Einstellungen → Integrationen** und scrolle zum Abschnitt **Bring your own OAuth Client**. Du siehst eine Liste der OAuth-Integrationen mit dem jeweils aktuellen Client-Status.

    <img src="https://mintcdn.com/langdock-34/JSBOyLaI-2nGZohA/images/byo-oauth-1.png?fit=max&auto=format&n=JSBOyLaI-2nGZohA&q=85&s=64c99e246a1fd9e5649c74cada416292" alt="Byo Oauth 1 Pn" width="1762" height="984" data-path="images/byo-oauth-1.png" />

    Wähle je nach aktuellem Status der Integration eine der folgenden Optionen:

    * Wenn für die Integration ein **Langdock-Client** verfügbar ist, öffne das Dropdown und wähle **Eigener Client**, um den Konfigurationsdialog zu öffnen.
    * Wenn kein Langdock-Client existiert und auch noch kein eigener Client konfiguriert ist, klicke auf **Konfigurieren**.
    * Wenn kein Langdock-Client existiert und dein eigener Client bereits konfiguriert ist, siehst du **Eigener Client** zusammen mit einer **Bearbeiten**-Schaltfläche. Klicke auf **Bearbeiten**, um deine Konfiguration anzupassen.

          <img src="https://mintcdn.com/langdock-34/JSBOyLaI-2nGZohA/images/byo-oauth-2.png?fit=max&auto=format&n=JSBOyLaI-2nGZohA&q=85&s=419adc9c6430510074203b6d7f9e272d" alt="Byo Oauth 2 Pn" width="1166" height="878" data-path="images/byo-oauth-2.png" />

    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, **Sync scopes with enabled actions** 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](/de/admin/manage-integrations/manage-action-level-scopes).

    Trage anschließend deine **Client-ID** und dein **Client-Secret** ein (und bei Microsoft-Integrationen zusätzlich die **Tenant-ID**, falls abgefragt) und klicke auf **Speichern**.

    <Warning>
      Neue Verbindungen verwenden ab sofort deinen OAuth-Client und funktionieren nur, wenn die Zugangsdaten gültig sind. Bestehende Verbindungen funktionieren weiter, bis ihre Access Tokens ablaufen.
    </Warning>
  </Step>

  <Step title="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
  </Step>
</Steps>

## Interface der Integrationseinstellungen

Der Konfigurationsdialog enthält die folgenden Abschnitte:

<Tabs>
  <Tab title="Redirect URL">
    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:

    ```
    https://app.langdock.com/api/integrations/{integration-id}/callback
    ```

    <Warning>
      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.
    </Warning>
  </Tab>

  <Tab title="Scopes">
    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).
    * **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 **Sync scopes with enabled actions** 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.

    <Warning>
      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.
    </Warning>
  </Tab>

  <Tab title="Credentials">
    Gib die Zugangsdaten deiner OAuth-Anwendung ein:

    * **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
  </Tab>
</Tabs>

## Zurück zum Langdock-Client wechseln

Wenn du deinen eigenen Client nicht mehr verwenden und zurück zum Standard-Client von Langdock wechseln möchtest:

1. Öffne das Dropdown neben der Integration und wähle **Langdock-Client** aus.
2. Bestätige den Wechsel im Dialog.

Neue Verbindungen verwenden danach wieder den Langdock-Client. Bereits mit deinem eigenen Client hergestellte Verbindungen funktionieren weiter, bis ihre Access Tokens ablaufen.

## Häufige Konfigurationsfehler

<AccordionGroup>
  <Accordion title="redirect_uri_mismatch">
    **Ursache**: Die Redirect-URL stimmt zwischen Langdock und deiner OAuth-Anwendung nicht exakt überein.

    **Lösung**:

    * Kopiere die Redirect-URL aus Langdock exakt
    * Achte auf abschließende Schrägstriche oder unterschiedliche Protokolle
    * Prüfe, ob du die richtige Umgebung konfigurierst
  </Accordion>

  <Accordion title="invalid_client">
    **Ursache**: Client-ID oder Client-Secret ist falsch.

    **Lösung**:

    * Überprüfe die Zugangsdaten aus deiner OAuth-Anwendung
    * Achte darauf, dass keine zusätzlichen Leerzeichen oder Zeichen enthalten sind
    * Stelle sicher, dass der Client in der Konsole deines Anbieters aktiviert ist
  </Accordion>

  <Accordion title="consent_required">
    **Ursache**: Admin-Zustimmung erforderlich, aber nicht erteilt.

    **Lösung**:

    * Erteile die Admin-Zustimmung in deinen Tenant-Einstellungen
    * Aktiviere ggf. die Zustimmung durch Nutzer, falls dies für deine Organisation passend ist
    * Prüfe die Anforderungen an Tenant-Freigabelisten
  </Accordion>

  <Accordion title="insufficient_scope">
    **Ursache**: Fehlende erforderliche Scopes in deiner OAuth-Anwendung.

    **Lösung**:

    * Füge alle in Langdock angezeigten Scopes zu deiner OAuth-Anwendung hinzu
    * Nutzer müssen sich nach dem Hinzufügen ggf. erneut verbinden
    * Verifiziere, dass die Namen der Scopes exakt übereinstimmen (Groß-/Kleinschreibung beachten)
  </Accordion>
</AccordionGroup>

***

## 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.

### ServiceNow

<Expandable title="wie du einen ServiceNow-OAuth-Client konfigurierst" collapsible>
  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](https://www.servicenow.com/docs/r/xanadu/security-management/security-incident-response/configure-application-registry-splunk.html?contentId=CHQRQznfzOrL_mxxa8MoCA) folgen.

  \
  **Erforderliche Input-Felder für die Authentifizierung**

  * ServiceNow-Subdomain angeben

  Wenn ein Nutzer eine Verbindung mit ServiceNow herstellen möchte, muss er die Subdomain deiner ServiceNow-Instanz angeben.

  ### Anforderungen für die ServiceNow-Integration

  <AccordionGroup>
    <Accordion title="Werden selbst gehostete oder cloudbasierte Konten unterstützt?">
      Derzeit werden nur cloudbasierte Konten unterstützt.
    </Accordion>

    <Accordion title="Ist ein bezahlter ServiceNow-Plan erforderlich?">
      Ein bezahltes ServiceNow-Konto ist erforderlich, um eine Application Registry zu erstellen. Mehr Informationen [hier](https://www.servicenow.com/lpgp/pricing.html?campid=107977\&cid=p:all:dg:b:prsp:exa:Google_CoreBrand_Top_Restructure:latam:mx\&ds_c=GOOG_LATAM_MX_ES_DEMANDGEN_ALBU_PRSP_Brand_EXA_Top-RES\&cmcid=71700000102193357\&ds_ag=Servicenow+Pricing_EXA_EN\&cmpid=58700008155106586\&ds_kids=p74103339564).
    </Accordion>

    <Accordion title="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](https://www.servicenow.com/docs/bundle/zurich-platform-security/page/integrate/identity/task/view-permissions-for-a-group.html).
    </Accordion>

    <Accordion title="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](https://www.servicenow.com/docs/bundle/zurich-api-reference/page/integrate/inbound-rest/concept/inbound-REST-API-rate-limiting.html).
    </Accordion>
  </AccordionGroup>
</Expandable>

### Snowflake

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.

<Expandable title="wie du einen Snowflake-OAuth-Client konfigurierst" collapsible>
  **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.

  <Note>
    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](/de/admin/security/static-ip-configuration) für Details.
  </Note>

  ### Einrichtungsanleitung

  <Steps>
    <Step title="Integration in Langdock erstellen">
      Erstelle in deinem Langdock-Arbeitsbereich eine neue Snowflake-Integration und richte einen eigenen OAuth-Client ein.

      <Expandable title="wie du einen eigenen OAuth-Client in Langdock einrichtest" collapsible>
        1. Navigiere zu Integrationen in Langdock
        2. Klicke auf **Add Integration** und wähle **Start from Scratch**
        3. Gib deinen bevorzugten Namen und eine Beschreibung für deine neue Snowflake-Integration ein
        4. Klicke auf **Create**
        5. Authentifizierungstyp: Wähle **OAuth 2.0** aus dem Dropdown
        6. Authentifizierungsfelder: Leer lassen
        7. OAuth-Konfiguration: Speichere deine **OAuth Redirect URL**
      </Expandable>
    </Step>

    <Step title="Security Integration in Snowflake erstellen">
      Wähle in Snowflake deinen Arbeitsbereich und erstelle eine neue Security Integration.

      <Expandable title="wie du eine neue Security Integration in Snowflake erstellst" collapsible>
        1. Erstelle eine neue `.sql`-Datei und füge folgende Abfrage ein:

        ```sql theme={null}
        CREATE SECURITY INTEGRATION <integration_name>
          TYPE = OAUTH
          ENABLED = TRUE
          OAUTH_CLIENT = CUSTOM
          OAUTH_CLIENT_TYPE = CONFIDENTIAL
          OAUTH_REDIRECT_URI = '<your_redirect_uri>'
          OAUTH_ISSUE_REFRESH_TOKENS = TRUE
          OAUTH_REFRESH_TOKEN_VALIDITY = 86400;
        ```

        2. Ersetze `<integration_name>` durch einen aussagekräftigen Namen und `<your_redirect_uri>` durch die **OAuth Redirect URL** aus Schritt 1.
        3. 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.
      </Expandable>
    </Step>

    <Step title="Client-ID und Client-Secret abrufen">
      <Expandable title="wie du die Client-ID und Client-Secret aus Snowflake abrufen kannst" collapsible>
        1. Führe im selben Arbeitsbereich folgende Abfrage aus:

        ```sql theme={null}
        SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('<integration_name>');
        ```

        2. Ersetze `<integration_name>` durch den Namen, den du deiner Security Integration im vorherigen Schritt gegeben hast.
        3. Speichere deine **Client-ID** und dein **Client-Secret**. Bewahre diese Zugangsdaten sicher auf, da sie Zugriff auf dein Snowflake-Konto ermöglichen.
      </Expandable>
    </Step>

    <Step title="Account-URL aus Snowflake abrufen">
      <Expandable title="wie du deine Account-URL aus Snowflake abrufst" collapsible>
        1. Klicke auf deinen Kontonamen in der unteren linken Ecke deiner Snowflake-Anwendung
        2. Klicke im Bereich **Account** auf **View Account Details**
        3. Kopiere deine **Account-URL**
      </Expandable>
    </Step>

    <Step title="Integrationseinstellungen in Langdock konfigurieren">
      <Expandable title="wie du deinen Snowflake-OAuth-Client in Langdock konfigurierst" collapsible>
        1. Füge deine **Client-ID** und dein **Client-Secret** aus Schritt 3 in die entsprechenden Eingabefelder deiner neuen Langdock-Integration ein
        2. In den folgenden Abschnitten:

        * Authorization URL
        * Access Token URL
        * Refresh Token URL

        Ersetze nur `https://example.com` durch deine **Snowflake Account-URL** aus Schritt 4.

        Beispiel:

        ```
        https://example.com/oauth/authorize
        ```

        Wird zu:

        ```
        https://<deine-snowflake-account-url>/oauth/authorize
        ```

        3. Klicke auf **Save**
      </Expandable>
    </Step>

    <Step title="Verbindung testen">
      <Expandable title="wie du eine Verbindung zu deiner Snowflake-Integration hinzufügst" collapsible>
        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!
      </Expandable>
    </Step>
  </Steps>
</Expandable>