Salesforce OAuth-Flows: das richtige Authentifizierungsdesign wählen

Wie wählen Sie den richtigen Salesforce OAuth-Flow? Führen Sie einen Menschen durch den Authorization Code Flow mit PKCE, binden Sie einen Server-to-Server-Job an den JWT Bearer Flow (oder den Client Credentials Flow) und greifen Sie nie auf Benutzername, Passwort und Security Token zurück, nur weil das schneller eingerichtet ist. Für diese Abkürzung läuft jetzt die Zeit ab. Salesforce hat die Einstellung des OAuth 2.0 Username-Password Flow für Connected Apps in Spring '26 angekündigt, sie zunächst für die Durchsetzung mit dem Winter '27-Rollout vorgesehen und dann auf ein einziges festes Datum gelegt: den 20. Februar 2027. Dieses Datum gilt für jede Org auf der Plattform gleich und ist nicht an das Upgrade-Wochenende Ihrer Instanz gebunden, ein gestaffeltes Zeitfenster, hinter dem Sie sich verstecken könnten, gibt es also nicht. Orgs, die in Summer '23 oder später erstellt wurden, blockieren den Flow bereits vollständig. Wählen Sie das falsche Design, sperren Sie entweder legitime Integrationen aus Ihrer Org aus oder lassen einen langlebigen Zugangsnachweis dort liegen, wo ein Angreifer ihn finden kann.

Wie wählen Sie den richtigen Salesforce OAuth-Flow?

Jede OAuth-Entscheidung beginnt mit einer Frage: Autorisiert eine Person diese Verbindung oder eine Maschine?

Ist eine Person anwesend, führen Sie sie durch den Authorization Code Flow mit PKCE (Proof Key for Code Exchange), den Salesforce als OAuth 2.0 Web Server Flow mit der PKCE-Erweiterung dokumentiert und nun als empfohlenen Ersatz für benutzerbasierte Logins nennt. PKCE bindet den Autorisierungscode an den Client, der ihn angefordert hat, sodass ein abgefangener Code für einen Angreifer wertlos ist. Bevorzugen Sie ihn gegenüber dem OAuth 2.0 Device Flow, den Salesforce zurückfährt: Am 2. September 2025 wurde die Device-Flow-Unterstützung aus der automatisch installierten Connected App von Data Loader entfernt, und Data Loader 64.1.0 hat sowohl den Device Flow als auch den User-Agent Flow gestrichen. Beide ließen sich leicht missbrauchen, weil sie mit kaum mehr als einer Client-ID gestartet werden konnten, ein beliebtes Ziel für Social Engineering.

Ist keine Person anwesend, etwa bei einem nächtlichen ETL-Job oder bei Middleware, die Datensätze an Salesforce sendet, wählen Sie einen Server-to-Server-Flow: den JWT Bearer Flow oder den Client Credentials Flow. Mit beiden authentifiziert sich ein Backend-Dienst ohne Browser oder Sitzung für eine Weiterleitung. Dieselbe Entweder-oder-Wahl liegt den meisten Integrationsarchitektur-Mustern zugrunde, die wirklich skalieren, denn das Authentifizierungsdesign muss jede Wiederholung, jedes Timeout und jede Rotation von Zugangsdaten überstehen, die diese Muster mit sich bringen.

JWT Bearer oder Client Credentials: Welcher Server-to-Server-Flow?

Beide Flows authentifizieren die App selbst ohne Benutzer, unterscheiden sich aber im Umgang mit Secrets.

• JWT Bearer Flow authentifiziert sich mit einem digital signierten Zertifikat statt mit einem gemeinsamen Secret. Es liegt kein Client Secret in einer Konfigurationsdatei, das durchsickern könnte, die signierte Assertion ist kurzlebig, und eine Schlüsselrotation bedeutet, ein Zertifikat zu tauschen, statt Code neu zu deployen. Greifen Sie dazu, wenn Sie die stärkste Absicherung wollen und einen privaten Schlüssel verwalten können.
• Client Credentials Flow tauscht Consumer Key und Consumer Secret gegen ein Access Token und läuft als festgelegter Integrationsbenutzer. Er ist einfacher einzurichten, aber das Secret ist ein Bearer Credential: Wer es abfängt, kann sich als die Integration ausgeben, deshalb muss es mit echter Disziplin gespeichert und rotiert werden.

Egal wofür Sie sich entscheiden, beschränken Sie den ausführenden oder Integrationsbenutzer eng mit einem eigenen Profil und Permission Sets, statt aus Bequemlichkeit breiten Admin-Zugriff zu gewähren. Ein Maschinenkonto, das nur die benötigten Objekte berühren kann, ist der Unterschied zwischen einem begrenzten Vorfall und der Kompromittierung der gesamten Org.

Connected Apps oder External Client Apps: Was hat sich für 2026 geändert?

Salesforce teilt die klassische Connected App in zwei zweckgebundene App-Typen auf, und der Zeitplan erzwingt nun die Entscheidung. Seit Spring '26 blockiert Salesforce das Erstellen neuer Connected Apps über UI und API, einzige Ausnahme ist die Package-Installation, und empfiehlt stattdessen External Client Apps. Bestehende Connected Apps funktionieren während und nach der Änderung weiter: Am Upgrade-Wochenende fällt in Ihrer Org nichts aus. Falls Sie wirklich eine neue Connected App erstellen müssen, kann der Salesforce Support das Erstellen für Ihre Org vorerst wieder aktivieren, doch Salesforce hat angekündigt, dass diese Möglichkeit in einem späteren Release entfällt. Das ist also eine Brücke, kein langfristiger Plan.

External Client Apps sind der neuere, empfohlene Weg für jedes externe System, das sich per OAuth bei Salesforce authentifiziert, einschließlich Ihrer eigenen Middleware, ETL-Tools und Partnerintegrationen. Sie sind bewusst strenger: Sie unterstützen nur die sicheren OAuth-Flows und schließen den Username-Password Flow vollständig aus. Außerdem unterstützen sie die Metadata API vollständig und halten Consumer Secrets aus paketierten Komponenten heraus, was sie über Versionskontrolle und CI/CD-Pipelines weit leichter verwaltbar macht als eine alte Connected App.

Die praktische Konsequenz für ein Architektur-Review: Nutzen Sie für neue Integrationen standardmäßig eine External Client App, und behalten Sie Connected Apps den Salesforce-nativen Fällen vor, die sie noch brauchen, etwa Canvas und Mobile Publishing. Wer aus Gewohnheit zu einer alten Connected App greift, stößt beim nächsten Build auf eine Erstellungssperre.

Wo passen Named Credentials in ein sicheres Integrationsdesign?

Named Credentials lösen ein anderes Problem: ausgehende Callouts von Salesforce an externe Systeme, gesteuert durch Apex oder Flow. Statt eine Endpoint-URL und OAuth-Details fest in einer Klasse zu kodieren, registrieren Sie einmal eine Named Credential und verweisen per Namen darauf, pro Benutzer oder org-weit, und Salesforce übernimmt Token-Austausch und Erneuerung im Hintergrund.

Für die Security Review ist das wichtig, weil Zugangsdaten vollständig aus dem Code verschwinden. Ob der zugrunde liegende Handshake JWT Bearer oder Client Credentials ist, Secret oder Schlüssel liegen außerhalb Ihres Integrationscodes, sodass die Rotation an einer Stelle stattfindet, statt Apex-Klassen und Flow-Definitionen zu durchsuchen. Wenn Sie Salesforce mit einem schwergewichtigen führenden System wie einem ERP verbinden, hält genau das die Integrationsmuster für Salesforce und SAP prüfbar, statt in einem Haufen eingebetteter Passwörter zu enden.

Wie migrieren Sie alte Username-Password-Integrationen auf moderne OAuth-Flows?

Die meisten Orgs, die wir prüfen, haben noch mindestens eine Integration, die sich mit Benutzername, Passwort und Security Token authentifiziert, manchmal aus einem Skript, an dessen Entstehung sich niemand erinnert. Der Stichtag 20. Februar 2027 hat sich schon einmal verschoben, von der Durchsetzungsliste für Winter '27, also betrachten Sie die zusätzliche Zeit als Migrationszeit, nicht als Gnadenfrist. In der UI gibt es keinen Warnhinweis: Am Stichtag erhält eine passwortbasierte Integration einfach kein Access Token mehr und gibt einen Authentifizierungsfehler zurück. Eine strukturierte Migration sieht so aus:

• Erfassen Sie jeden Integrationsbenutzer und jedes API-fähige Profil, um herauszufinden, wo passwortbasierte Logins noch genutzt werden.
• Ordnen Sie jede Integration als Benutzer-anwesend oder Server-to-Server ein und weisen Sie sie dem Authorization Code Flow mit PKCE, dem JWT Bearer Flow oder dem Client Credentials Flow zu.
• Registrieren Sie pro Integration eine eigene External Client App, statt eine App über voneinander unabhängige Systeme hinweg zu teilen.
• Verlagern Sie ausgehende Callouts hinter Named Credentials, damit Secrets außerhalb der Codebasis liegen.
• Ändern Sie das Passwort des alten Integrationsbenutzers und widerrufen Sie seinen API-Zugriff, sobald der Datenverkehr vollständig umgestellt ist.

Führen Sie die Umstellung Integration für Integration durch und bestätigen Sie in einer Sandbox, dass sich jede Verbindung authentifiziert, bevor Sie den Zugangsnachweis anfassen, von dem die Produktion abhängt. Dasselbe Authentifizierungsdesign trägt auch neuere Muster wie CRM-Aktionen aus einem agentischen Hub ausführen, bei denen eine einzige Maschinenidentität auf viele Aktionen zugreift und ein durchgesickertes Secret umso größeren Schaden anrichten würde.

Diese Art von Arbeit erledigt unser Beratungsteam regelmäßig. Wenn Ihre Org noch passwortbasierte Integrationen betreibt, können wir den Migrationspfad festlegen, lange bevor der 20. Februar 2027 daraus einen Notfall macht. Nehmen Sie Kontakt auf, um über Ihr Setup zu sprechen.

FAQ

Wann wird der Salesforce Username-Password OAuth-Flow eingestellt?

Salesforce hat die Einstellung vom Winter '27-Rollout auf ein einziges festes Datum verschoben, den 20. Februar 2027, das für alle Orgs gleichzeitig gilt und nicht dem Upgrade-Wochenende der jeweiligen Org folgt. Orgs, die in Summer '23 oder später erstellt wurden, blockieren den Flow bereits. Migrieren Sie betroffene Integrationen vorher auf den Web Server Flow mit PKCE, den JWT Bearer Flow oder den Client Credentials Flow.

Kann ich 2026 noch eine neue Connected App erstellen?

Salesforce schränkt das Erstellen neuer Connected Apps seit Spring '26 ein und empfiehlt stattdessen External Client Apps. Bestehende Connected Apps funktionieren weiter, und Sie können über den Salesforce Support eine Ausnahme beantragen, wenn Sie wirklich eine brauchen.

Was ist der Unterschied zwischen JWT Bearer und Client Credentials Flow?

Beide sind Server-to-Server-Flows ohne anwesenden Benutzer. JWT Bearer authentifiziert sich mit einem signierten Zertifikat und hat kein gemeinsames Secret, das durchsickern könnte, während Client Credentials einen Consumer Key und ein Secret eintauscht und als festgelegter Integrationsbenutzer läuft. Das ist einfacher, beruht aber auf einem Bearer Secret, das Sie sorgfältig speichern und rotieren müssen.

Sollten neue Integrationen Connected Apps oder External Client Apps verwenden?

Nutzen Sie für neue externe Integrationen standardmäßig External Client Apps. Sie unterstützen nur die sicheren OAuth-Flows, arbeiten für CI/CD vollständig mit der Metadata API und sind der Weg, den Salesforce jetzt empfiehlt. Behalten Sie Connected Apps Salesforce-nativen Fällen wie Canvas und Mobile Publishing vor.

Ersetzen Named Credentials OAuth-Flows?

Nein. Named Credentials verwalten die Authentifizierung ausgehender Callouts und können im Hintergrund OAuth-Flows wie JWT Bearer nutzen. Sie halten Secrets aus Apex und Flow heraus, ersetzen den Flow aber nicht.