Ich versuche, n8n über das integrierte OAuth 2.0 mit der API von Zoho zu verbinden
Nach Ausprobieren wurde mir berichtet, dass n8n den Token nicht mit dem korrekten Grant-Type aktualisiert
„Wir haben das gemeldete Problem mit unserem Backend-Team überprüft, und unsere Entwickler haben festgestellt, dass das Problem auftritt, weil der Grant-Type-Parameter nicht auf refresh_token gesetzt ist.„
Das ist ein bekanntes Verhalten, wie n8n OAuth2 handhabt, aber es ist typischerweise ein Setup-/Konfigurationsproblem und kein Bug. n8n unterstützt den refresh_token Grant-Type, aber die Zoho-API ist notorisch streng bezüglich der Formatierung der Refresh-Anfrage (verlangt speziell, dass grant_type im Request-Body und nicht in der Query-String steht, sowie spezifische Client-Anmeldedaten).
Je nachdem, welchen Credential-Block du verwendest, ist hier die Lösung. Schau, welche passt:
Wenn du den integrierten Zoho-Node verwendest, stelle sicher, dass du die richtige Zoho-API ausgewählt hast (z. B. Zoho CRM, Zoho Books), da diese unterschiedliche Scopes haben.
Wenn du den HTTP Request Node mit Generic OAuth2 verwendest, konfiguriere die Anmeldedaten wie folgt:
Scope: (Stelle sicher, dass du die erforderlichen exakten Scopes hast, z. B. ZohoCRM.modules.ALL)
Auth URI Query Parameters: Füge access_type=offline und prompt=consent hinzu.
KRITISCH: Ohne access_type=offline wird Zoho keinen Refresh-Token ausstellen, und n8n wird die Sitzung nicht aktualisieren können, was zu dem Fehler führt, den du erhalten hast.
Hi @taamtera
n8n unterstützt den refresh_token grant, also ist dies keine fehlende Funktion. Zohos Token-Endpunkt ist die Ausnahme: In der eigenen Dokumentation sind grant_type, client_id, client_secret und refresh_token als Query-String-Parameter für /oauth/v2/token aufgelistet, und es wird angegeben, dass der Endpunkt diese nicht als Body-Objekt akzeptiert, weshalb Zohos Backend-Team keinen grant_type beim Refresh-Aufruf sieht.
Der zuverlässige Weg ist, sich nicht auf die automatische Aktualisierung der Anmeldedaten zu verlassen und diese selbst durchzuführen. Rufen Sie das Refresh-Token einmal ab, speichern Sie es, aktualisieren Sie dann mit einem HTTP Request Node, der an die URL des Rechenzentrums POSTet und die Parameter in der Query-String sendet:
Verwenden Sie die Accounts-Domain des Rechenzentrums, das das Token ausgestellt hat (.eu, .in, .com.au, .ca), ein Token von einem Rechenzentrum wird nicht gegen ein anderes aktualisiert.
Siehe dazu:
n8n unterstützt den Refresh-Token-Grant. Der aktuelle OAuth-Client erstellt den Token-Request-Body mit refresh_token und grant_type: refresh_token. Die integrierte Zoho-Anmeldedaten nutzen den Authorization-Code-Flow, fordern access_type=offline an, senden die Client-Authentifizierung im Body und stellen die regionsspezifische Zoho-Token-URL bereit.
Versuchen Sie nicht, refresh_token als initialen Grant Type der Anmeldedaten auszuwählen. Dies ist der Refresh-Schritt innerhalb einer Authorization-Code-Anmeldedaten, keine separate Setup-Option.
Das fehlende Detail ist Ihre n8n-Version und der genaue Anmeldedatentyp. Wenn dies die integrierte Zoho-Anmeldedaten sind, bestätigen Sie, dass die Access Token URL Ihrem Zoho-Rechenzentrum entspricht. Verbinden Sie die Anmeldedaten erneut, damit n8n einen neuen Offline-Refresh-Token speichert, und versuchen Sie es dann erneut.
Wenn Zoho immer noch einen Token-Request ohne grant_type in der aktuellen n8n-Version aufzeichnet, handelt es sich um einen reproduzierbaren Bug. Geben Sie in dem Bericht die Version, den Anmeldedatentyp, den Token-Endpoint-Host sowie ein redigiertes Zoho-Request-Log an. Fügen Sie keine Tokens oder Client-Secrets ein.