Wir erleben ein OAuth2-Authentifizierungsproblem mit dem standardmäßigen Salesforce-Connector auf n8n Cloud.
Umgebung
n8n Cloud
Salesforce Sandbox
Standardmäßige Salesforce OAuth2-Berechtigung
n8n Connected App installiert
Benutzer dürfen sich selbst autorisieren
IP-Beschränkungen sind gelockert
Verhalten
Authentifizierung mit einem SSO-aktivierten Salesforce-Benutzer funktioniert erfolgreich.
Authentifizierung mit Salesforce-Benutzern, die Benutzername/Passwort verwenden, schlägt fehl nach erfolgreicher Anmeldung und Autorisierung.
Die Salesforce-Anmeldehistorie zeigt die Authentifizierung als erfolgreich an und der Autorisierungscode wird an n8n zurückgegeben. Der nachfolgende Token-Austausch schlägt fehl mit:
invalid_grant
authentication failure
Erwartetes Verhalten
Sowohl SSO- als auch Benutzername/Passwort-Salesforce-Benutzer sollten den OAuth2-Flow erfolgreich abschließen können.
Könnten Sie bitte überprüfen, warum der Token-Austausch speziell für Nicht-SSO-Benutzer in einer Salesforce Sandbox fehlschlägt?
Wenn du dich über OAuth2 authentifizierst und Verbindungs- oder Autorisierungsfehler auftreten, fehlen Salesforce-Benutzerprofilen oft eine erforderliche Berechtigung
Navigiere in Salesforce zu Setup > suche nach Profiles.
Wähle das Benutzerprofil aus, das sich verbinden möchte.
Aktiviere unter Administrative Permissions die Option Approve Connected Apps for Non-Admins (oder Approve apps connected not installed).
Speichere deine Änderungen.
Außerdem erfordert OAuth2 das Erstellen einer External Client App (oder einer Legacy Connected App) in Salesforce mit den Bereichen Full access (full) und Perform requests at any time (refresh_token, offline_access)
Stelle bei Connected App sicher, dass die OAuth-Richtlinien in Salesforce das Benutzerprofil unter Manage Profiles oder Manage Permission Sets zulassen
Der betroffene Benutzer hat Salesforce System Administrator-Berechtigungen. Die n8n Connected App ist installiert, All users may self-authorize ist aktiviert und IP-Beschränkungen sind gelockert.
Dieselbe n8n Salesforce OAuth-Integration funktioniert mit einem SSO-aktivierten Benutzer. Bei einem Benutzer mit Benutzername/Passwort werden Salesforce-Authentifizierung und -Autorisierung erfolgreich abgeschlossen und die Salesforce-Anmeldungshistorie zeigt Remote Access Client: Success. Ein Autorisierungscode wird an n8n zurückgegeben.
Der Fehler tritt nur während des nachfolgenden Token-Austauschs auf: invalid_grant / authentication failure
Daher scheint dies kein Problem mit Connected App-Genehmigung oder Profilberechtigung zu sein. Können Sie bitte den von n8n durchgeführten Token-Austausch überprüfen und prüfen, ob es einen Unterschied bei der Behandlung von Sandbox-Benutzern gibt, die sich über Benutzername/Passwort gegenüber SSO authentifizieren?
Der Fehler wird wahrscheinlich durch einen Endpunkt-Mismatch der Umgebung während des OAuth-Handshakes verursacht. Während die Autorisierungsphase erfolgreich ist, weil die Anmeldedaten gültig sind, schlägt der nachfolgende Token-Austausch mit invalid_grant fehl, weil n8n wahrscheinlich versucht, den Autorisierungscode am falschen Endpunkt auszutauschen (z. B. unter Verwendung der Production-URL login.salesforce.com für einen Code, der über die Sandbox-URL test.salesforce.com generiert wurde).
Diese Diskrepanz tritt speziell bei Benutzern mit Benutzername/Passwort auf, weil diese auf die vom Client bereitgestellte Basis-URL angewiesen sind. Im Gegensatz dazu werden SSO-Benutzer über einen externen Identity Provider (IdP) weitergeleitet, der den Authentifizierungspfad explizit definiert und dadurch jeden Mismatch zwischen Autorisierungs- und Austausch-Endpunkten effektiv verdeckt.
Um dieses Problem zu beheben, überprüfen Sie, dass die Einstellung „Umgebung
Danke, das stimmt mit unseren Beobachtungen überein.
Die Anmeldedaten sind bereits für Sandbox konfiguriert, und wir verwenden die Custom Domain Workaround. Wir haben verifiziert, dass die Autorisierungsanfrage über den korrekten Salesforce Sandbox/MyDomain-Endpunkt geleitet wird.
Könnten Sie bitte auf der n8n-Seite verifizieren, welcher Token-Endpunkt tatsächlich für den Code-Austausch verwendet wird?
Genauer gesagt möchten wir ausschließen, dass der Autorisierungscode, der über den Sandbox/MyDomain-Endpunkt generiert wurde, anschließend gegen login.salesforce.com oder einen anderen nicht übereinstimmenden Endpunkt ausgetauscht wird.
Da der Token-Austausch serverseitig von n8n Cloud durchgeführt wird, können wir dies von unserer Seite aus nicht verifizieren.
Hallo @mevaco_chris Willkommen!
Um direkt auf den Endpoint zu antworten: Die Salesforce OAuth2-Anmeldedaten leiten die Token-URL nur aus dem Environment Type ab, also postet n8n mit ausgewählter Sandbox den Code jedes Mal auf https://test.salesforce.com/services/oauth2/token. Es ist ein verborgenes Feld ohne Override-Option, deshalb kann ein Code, der über die Custom Domain-Anmeldung auf deinem MyDomain-Host ausgestellt wurde, nicht eingelöst werden und kommt als invalid_grant zurück.
Wechsle den Salesforce-Node zu OAuth2 JWT und setze das Feld My Domain URL auf der JWT-Anmeldedaten auf deine Sandbox-Domain: https://company--sandbox.sandbox.my.salesforce.com
Dieses Feld setzt sowohl die Assertion Audience als auch den Token Endpoint außer Kraft, sodass der Austausch auf demselben Host landet, der die Genehmigung ausgestellt hat. Es entfernt auch die interaktive Anmeldung vollständig, sodass SSO- und Benutzername/Passwort-Benutzer denselben Weg gehen. Du benötigst eine External Client App mit aktiviertem JWT Bearer Flow und ein hochgeladenes Zertifikat.
Danke für die Klarstellung. Das erklärt den invalid_grant-Fehler.
Das Wechseln zu JWT wirkt jedoch eher wie ein Workaround als wie eine Lösung für das zugrunde liegende Problem.
Wenn die Salesforce OAuth2-Anmeldedaten für Sandbox-Umgebungen immer test.salesforce.com als Token-Endpunkt verwenden, während die Authentifizierung über eine Sandbox MyDomain erforderlich/unterstützt ist, kann das Standard-OAuth2-Zertifikat diesen Flow derzeit nicht korrekt abschließen.
Das Wechseln zu JWT würde erfordern, dass wir ein separates Authentifizierungssetup, einschließlich einer externen Client-App, eines Zertifikats und einer Verwaltung des Lebenszyklus des privaten Schlüssels, nur als Workaround für diese Einschränkung einführen und verwalten.
Gilt dies als bekannte Einschränkung/Bug der Salesforce OAuth2-Anmeldedaten? Falls ja, existiert bereits ein Issue oder eine geplante Lösung, um den Token-Endpunkt so zu konfigurieren, dass auch die konfigurierte MyDomain verwendet werden kann?
Unser Wunsch wäre es, die Standard-Salesforce OAuth2-Anmeldedaten wie vorgesehen zu verwenden, anstatt die Authentifizierungsarchitektur als Workaround zu ändern.
invalid_grant klingt nach einem potenziellen Scope-Problem, was seltsam ist, da wir full und refresh_token senden. Aus Interesse – hast du PKCE in deiner Salesforce-App aktiviert?