Provider-Verbindungen einrichten

Richten Sie Provider-Verbindungen ein, wenn Workspace mit einem externen Dienst Daten austauschen soll und dieser Dienst OAuth verwendet. Nach Abschluss existiert ein tenant-gebundenes, verschlüsseltes Credential, das andere Workspace-Funktionen als Credential-ID referenzieren können.

Provider-Verbindungen sind kein Google-Sonderweg. Workspace registriert unterstützte Provider im Backend und zeigt sie im Admin-Wizard an. Der erste Schnitt unterstützt Google Merchant Center und Google Search Console. Weitere OAuth-basierte Dienste können später denselben Vertrag nutzen, wenn ein Backend-Adapter ihre Scopes, Fähigkeiten und Tests deklariert.

Wenn Ihr Ziel Google Merchant Center ist, führen Sie den fachlichen Ablauf in Product Channel Sync für Google Merchant Center einrichten aus. Diese Seite erklärt nur, wie Sie das dafür benötigte OAuth-Credential anlegen oder prüfen.

Wann Sie diese Seite verwenden

Nutzen Sie diese Anleitung in drei Situationen:

Nach einem Release müssen bestehende OAuth-Verbindungen normalerweise nicht neu autorisiert werden. Workspace nutzt weiterhin provider_auth_tokens als verschlüsselten Token-Speicher. Prüfen Sie bestehende Verbindungen nur operativ. Verbinden Sie neu, wenn der Verbindungstest fehlschlägt, der Scope nicht passt oder der Provider den Zugriff widerrufen hat.

Voraussetzungen

Prüfen Sie diese Punkte, bevor Sie eine Verbindung anlegen:

Für Tests und Aufräumen benötigen Sie zusätzlich:

Arbeitsablauf

Arbeiten Sie eine Provider-Verbindung immer in dieser Reihenfolge ab:

1. Workspace-Tenant und Rechte prüfen.
2. Provider-Konto, API und OAuth-App beim externen Dienst vorbereiten.
3. Provider im Workspace-Wizard wählen.
4. JavaScript-Origin, Redirect URI und Scopes aus Workspace in den OAuth-Client des Providers eintragen.
5. Bei Google-Providern die Google Auth Platform prüfen: Zielgruppe, Testnutzer, App-Freigabe und erlaubte Scopes müssen zum OAuth-Client passen.
6. Client ID und Client Secret aus dem Provider-Portal in Workspace erfassen.
7. Verbindung testen.
8. Credential-ID aus der Verbindungsliste übernehmen.
9. Fachliches Binding anlegen, zum Beispiel Search-Console-Binding oder Product-Channel-Binding.
10. Nachgelagerten Sync oder Import testen.

Die Einrichtung ist erst abgeschlossen, wenn sowohl die Provider-Verbindung als auch das fachliche Binding erfolgreich geprüft wurden.

Verbindung anlegen

1. Öffnen Sie in Workspace System > Integrationen > Provider-Verbindungen.
2. Wählen Sie Provider verbinden.
3. Prüfen Sie im Schritt Bereitschaft die Provider-Voraussetzungen.
4. Wählen Sie den Provider, zum Beispiel Google Merchant Center oder Google Search Console.
5. Kopieren Sie im Schritt OAuth-App den autorisierten JavaScript-Origin, die autorisierte Redirect URI und die angezeigten Scopes in den OAuth-Client des Providers.
6. Prüfen Sie bei Google-Providern, ob der anmeldende Google-Nutzer die App verwenden darf. Fügen Sie ihn im Testing-Modus als Testnutzer hinzu oder lassen Sie die OAuth-App durch den Google-Workspace-Admin freigeben.
7. Erzeugen Sie im Provider-Portal Client ID und Client Secret.
8. Erfassen Sie die Konto-ID des Providers, Client ID und Client Secret in Workspace.
9. Öffnen Sie die Zustimmung und schließen Sie den OAuth-Dialog im selben Browser ab.
10. Prüfen Sie nach der Rückkehr, ob die Verbindung in der Liste als aktiv erscheint.

Workspace zeigt die Credential-ID in der Verbindungsliste unter dem Provider- Konto an. Nutzen Sie diese ID in nachgelagerten Bindings, zum Beispiel für Google Search Console oder Product Channel Sync.

Bestehende Verbindung nach Release prüfen

Prüfen Sie vorhandene Verbindungen nach einem Release ohne Re-Consent:

1. Öffnen Sie System > Integrationen > Provider-Verbindungen.
2. Suchen Sie die Verbindung nach Provider und Konto-ID.
3. Prüfen Sie, ob eine Credential-ID angezeigt wird.
4. Wählen Sie Testen.
5. Prüfen Sie das fachliche Binding, das diese Credential-ID verwendet.
6. Starten Sie den kleinsten sinnvollen fachlichen Testlauf, zum Beispiel einen Search-Console-Test-Sync oder einen Product-Channel-Readiness-Lauf.

Sie müssen nur neu verbinden, wenn einer dieser Punkte zutrifft:

Wenn Sie neu verbinden und dieselbe Konto-ID verwenden, aktualisiert Workspace den vorhandenen provider_auth_tokens-Eintrag. Wenn eine neue Credential-ID entsteht, muss das nachgelagerte Binding diese neue ID verwenden.

Google Merchant Center

Für Google Merchant Center verwendet Workspace:

Aktivieren Sie im Google-Cloud-Projekt die Merchant API und richten Sie einen OAuth-Client ein, der die Redirect URI aus dem Workspace-Wizard erlaubt. Nach dem Verbinden legen Sie das Product-Channel-Binding an und tragen die Credential-ID sowie die Merchant Center Account ID ein. Die Details stehen in Product Channel Sync für Google Merchant Center einrichten.

Für Google Merchant Center reicht OAuth allein nicht immer aus. Wenn Google Merchant-API-Aufrufe mit einem nicht registrierten Google-Cloud-Projekt blockiert, führen Sie zusätzlich die Merchant API Developer Registration für das Google-Cloud-Projekt des OAuth-Clients aus. Bei Merchant-Unterkonten kann Google ein Haupt- oder Advanced-Konto für die Registrierung nennen; verwenden Sie dann dieses Konto für registerGcp und behalten Sie im Workspace-Binding das Ziel-Merchant-Konto für den Sync bei.

Wenn Google beim OAuth-Dialog „Diese App ist blockiert“ meldet, liegt der Fehler vor der Workspace-Verbindung. Prüfen Sie im richtigen Google-Cloud- Projekt die Google Auth Platform, den Veröffentlichungsstatus, Testnutzer, Scopes und eventuelle Google-Workspace-Admin-Regeln. Starten Sie den Workspace- OAuth-Dialog erst erneut, wenn Google die App zulässt.

Google Search Console

Für Google Search Console verwendet Workspace:

Aktivieren Sie im Google-Cloud-Projekt die Search Console API und richten Sie einen OAuth-Client ein, der die Redirect URI aus dem Workspace-Wizard erlaubt. Nach dem Verbinden legen Sie das Search-Console-Binding für Site, Property und Credential-ID an. Die Details stehen in Google Search Console einrichten.

Verbindung testen

Nutzen Sie Testen, um die gespeicherte Verbindung gegen den Provider- Adapter zu prüfen. Workspace prüft dabei den verschlüsselten Token-Lifecycle, die vom Provider-Adapter geforderten Scopes und die deklarierten Fähigkeiten.

Ein erfolgreicher Verbindungstest bedeutet, dass Workspace das Credential auflösen kann. Er ersetzt nicht die fachliche Readiness der nachgelagerten Funktion. Product Channel Sync prüft zum Beispiel zusätzlich Site-Domain, Vertriebskanal, öffentliche Produktdaten, Bilder, Preise und Binding- Konfiguration.

Mit nucli prüfen

nucli hat keinen eigenen OAuth-Onboarding-Befehl. Verwenden Sie für den OAuth-Dialog immer die Admin-Oberfläche, weil OAuth-Start eine Browser-Session, Origin-Prüfung, Redirect und Zustimmung im Browser braucht.

Für Betriebsprüfung und API-Inspektion können Administratoren nucli api nutzen:

nucli --tenant <tenant> api GET /api/v1/provider-connections/providers --summary
nucli --tenant <tenant> api GET /api/v1/provider-connections --redact --save provider-connections.json
nucli --tenant <tenant> api POST /api/v1/provider-connections/<credentialId>/test --summary

Verwenden Sie --redact oder --summary, wenn Sie Ausgaben in Tickets oder Betriebsprotokolle übernehmen. Geben Sie keine Client Secrets, OAuth-Codes, Access Tokens oder Refresh Tokens über nucli aus.

nucli api --web eignet sich hier nicht für das Onboarding. Es öffnet nur GET-Endpunkte im Browser und sendet keinen Request-Body für OAuth-Start.

Sicherheit

Workspace speichert OAuth-Credentials tenant-gebunden und verschlüsselt. Der OAuth-Flow ist zeitlich begrenzt, an Tenant und Benutzeridentität gebunden und nutzt State sowie PKCE. Antworten der Admin-API enthalten keine Client Secrets, Refresh Tokens oder verschlüsselten Secret-Felder.

Beim Entfernen trennt Workspace die Verbindung lokal und löscht die sensitiven Token-Metadaten. Workspace ruft in diesem Schnitt keine externe Revoke-API des Providers auf. Widerrufen Sie den Zugriff zusätzlich im Provider-Portal, wenn der externe Dienst das verlangt.

Brechen Sie die Einrichtung ab, wenn der OAuth-Client nicht zur aktuellen Workspace-Umgebung gehört, ein zusätzlicher nicht dokumentierter Scope verlangt wird oder die Redirect URI nicht exakt zur angezeigten URI passt.

Erfolg erkennen

Eine Provider-Verbindung ist arbeitsfähig, wenn diese Punkte erfüllt sind: