Tekunda Team

Aktualisiert vor 5 Monaten

Salesforce-Authentifizierung: vollständiger Migrationsguide

Q: Woher kommt der Fehler "invalid code verifier" bei PKCE?

Meist von einem fehlenden code_challenge_method=S256 oder von Standard-Base64 dort, wo base64url gefordert ist. Base64url ersetzt + und / durch - und _ und lässt das Padding weg.

Salesforce-Authentifizierung: vollständiger Migrationsguide

Salesforce-Authentifizierung im Wandel, Ihr vollständiger Migrationsguide

Im September 2025 führt Salesforce wichtige Änderungen an der Sicherheit von Connected Apps ein, die beeinflussen, wie Ihre Anwendungen authentifizieren. Zwei große Änderungen kommen:

Der OAuth 2.0 Device Flow wird blockiert.

Nicht installierte Connected Apps sind für die meisten Nutzer nicht mehr zugänglich.

Dieser Beitrag erklärt die Migration vom Device Login Flow zu Connected App OAuth2 Flow mit PKCE, warum die Änderung wichtig ist und wie Sie sich sicher vorbereiten.

Warum Salesforce Device Flow blockiert

Der Device Flow (RFC8628) hat eine bekannte Schwachstelle: Er kann nur mit einer client_id gestartet werden. Ein Angreifer kann das in Social-Engineering-Angriffen ausnutzen und Nutzer dazu bringen, nicht vertrauenswürdige Apps zu genehmigen.

Auswirkungen in der Praxis: Aktuelle prominente Vorfälle bei KLM Airfrance, Adidas, Google, Qantas und Allianz Life wurden von Gruppen wie UNC6040/ShinyHunters genau über diesen Angriffsvektor durchgeführt. Die Angreifer nutzten Social Engineering, etwa Telefonanrufe als angebliche IT-Mitarbeiter, um Beschäftigte zur Autorisierung bösartiger Connected Apps via Device Flow zu bewegen.

Salesforce hat bestätigt, dass diese Schwachstelle in Produktionsumgebungen ausgenutzt wurde. Die Abschaltung ist deshalb eine Sicherheitsnotwendigkeit, nicht nur ein technisches Upgrade.

Wechsel zu Connected App OAuth2 Flow mit PKCE

Der sichere Ersatz ist PKCE (Proof Key for Code Exchange), eine Erweiterung des Authorization Code Flow, die das Abfangen des Authorization Code verhindert.

Schritt 1: PKCE-Parameter generieren

Erstellen Sie einen code_verifier, einen zufälligen kryptografisch sicheren String mit 43-128 Zeichen.

Hashen Sie ihn mit SHA256 und encodieren Sie ihn mit base64url → code_challenge.

Wichtig: Verwenden Sie base64url encoding, nicht Standard-base64. Das ersetzt + durch -, / durch _ und entfernt Padding-Zeichen = für URL-Sicherheit.

Schritt 2: Authorization URL bauen

Stellen Sie sicher, dass der für PKCE wichtige Parameter enthalten ist:

code_challenge_method=S256

Beispiel:

https://login.salesforce.com/services/oauth2/authorize?
client_id=YOUR_CLIENT_ID&
response_type=code&
redirect_uri=YOUR_CALLBACK_URL&
scope=full refresh_token&
code_challenge_method=S256&
code_challenge=YOUR_CODE_CHALLENGE&
state=YOUR_RANDOM_STATE

Schritt 3: Authorization Code gegen Tokens tauschen

Senden Sie code und code_verifier zurück an Salesforce:

POST /services/oauth2/token
grant_type=authorization_code
client_id=YOUR_CLIENT_ID
code=AUTH_CODE
code_verifier=ORIGINAL_CODE_VERIFIER
redirect_uri=CALLBACK_URL

Schritt 4: Berechtigungen aktualisieren

Salesforce fügt neue Berechtigungen mit Regeln anhand Ihrer Org-Konfiguration hinzu:

Wenn API Access Control DEAKTIVIERT ist, was für die meisten Orgs gilt:

Nutzer können auf nicht installierte Apps mit einer dieser Berechtigungen zugreifen:

Approve Uninstalled Connected Apps (neu in Summer '25), für die meisten Fälle empfohlen
Use Any API Client, breitere Berechtigung, sparsam einsetzen

Wenn API Access Control AKTIVIERT ist:

Nur die Berechtigung Use Any API Client funktioniert für den Zugriff auf nicht installierte Apps.

Spezifische Änderungen für Data Loader

Kritische Frist: 2. September 2025, OAuth Device Flow Support endet in Data Loader.

Erforderliche Maßnahmen:

Authentifizierungsmethode wechseln vor dem 2. September:
- Password authentication (username + password + security token)
- OAuth Web Server Flow (empfohlen)
Data Loader aktualisieren, Salesforce veröffentlicht vor dem 2. September eine neue Version ohne Device Flow Support
Hinweis: Command-line Nutzung mit verschlüsselten Passwörtern bleibt unberührt

Häufige Migrationsprobleme

PKCE-Fehler ("invalid code verifier"): meist verursacht durch fehlenden Parameter code_challenge_method=S256 oder falsches base64url encoding.

Blockierter Nutzerzugriff nach September: beheben Sie dies durch Zuweisung der passenden Berechtigung anhand Ihres API Access Control-Status.

Data Loader Login-Fehler: migrieren Sie die Authentifizierungsmethode vor dem 2. September 2025.

Falsche Connected App-Konfiguration: setzen Sie bei installierten Apps "Permitted Users" auf "Admin approved users are pre-authorized" für bessere Sicherheitskontrolle.

Zeitplan und Aktionsplan

Sofortmaßnahmen (vor dem 2. September 2025)

Connected Apps auditieren:

Gehen Sie zu Setup → Connected Apps OAuth Usage
Suchen Sie nach "Install"-Buttons in der Actions-Spalte, sie weisen auf nicht installierte Apps hin

Device Flow-Nutzung identifizieren:

Fokus auf Data Loader-Nutzer
Prüfen Sie Custom Applications, die Device Flow verwenden

PKCE-Implementierung planen:

Aktuelle OAuth flows prüfen
Development-Ressourcen für PKCE-Migration vorbereiten

Migrationsphase (Aug–Sep 2025)

PKCE-fähigen OAuth flow implementieren:

Korrektes base64url encoding sicherstellen
Parameter code_challenge_method=S256 einbeziehen
Authorization und Token Exchange flows testen

In Salesforce sandbox testen:

PKCE-Implementierung validieren
User permission assignments testen
Data Loader-Alternativen prüfen

Connected Apps korrekt konfigurieren:

Vertrauenswürdige nicht installierte Apps mit "Install" installieren
"Permitted Users" auf "Admin approved users are pre-authorized" setzen
Zugriff über Permission Sets nach Least Privilege vergeben

Data Loader-Migration vorbereiten:

Nutzer zu neuen Authentifizierungsmethoden schulen
Dokumentation und Verfahren aktualisieren
Password authentication oder Web Server Flow testen

Nach der Migration (nach September 2025)

Authentifizierungslogs überwachen:

Fehlgeschlagene Authentifizierungsversuche beobachten
Connected App-Nutzungsmuster verfolgen
Security incidents überwachen

Nutzersupport bereitstellen:

Zugriffsprobleme schnell lösen
Nutzer bei neuen Authentifizierungsmethoden unterstützen
Häufige Troubleshooting-Schritte dokumentieren

Security Policies vierteljährlich prüfen:

Connected App-Berechtigungen regelmäßig auditieren
Nutzerzugriff auf sensible Integrationen prüfen
API Access Control für erhöhte Sicherheit erwägen

Empfehlungen für erhöhte Sicherheit

Optional, aber empfohlen: API Access Control aktivieren

Kontaktieren Sie Salesforce Support, um diese Funktion zu aktivieren. Sie bietet:

Allowlist-basierten Connected App-Zugriff
Granulare Kontrolle darüber, welche Apps Nutzer verwenden können
Proaktive Blockierung nicht autorisierter Anwendungen

Nutzerschulung ist kritisch

Nutzer darin schulen, Social-Engineering-Versuche zu erkennen
Klare Verfahren für Connected App-Zugriffsanfragen festlegen
Security Best Practices regelmäßig kommunizieren
Nutzer daran erinnern, unbekannte Anwendungen nie zu genehmigen

Governance Framework

Klares Ownership für jede Connected App definieren
Freigabeprozesse für neue Integrationen etablieren
Regelmäßige Access Reviews durchführen
Security-Teams in Connected App Policies einbinden

Wichtige Ausnahme

Bestehende Autorisierungen: Nutzer, die Connected Apps zuvor autorisiert haben, können sie nach September 2025 weiter verwenden, AUSSER diese Apps wurden über Device Flow autorisiert. Alle Device Flow-Autorisierungen werden unabhängig von früherer Nutzung sofort blockiert.

Fazit

Salesforces Abschaltung des Device Flow ist nicht nur ein technisches Upgrade. Sie ist eine kritische Sicherheitsreaktion auf reale Angriffe, die große Organisationen kompromittiert haben. Die jüngsten Vorfälle bei bekannten Unternehmen zeigen die Dringlichkeit dieser Sicherheitsverbesserungen.

Durch die Migration zu Connected App OAuth2 Flow mit PKCE und korrekt konfigurierte Berechtigungen können Organisationen:

sich vor Angriffen durch Abfangen von Authorization Codes schützen
Salesforces weiterentwickelte Sicherheitsanforderungen erfüllen
die Angriffsfläche für Social-Engineering-Kampagnen reduzieren
Business Continuity für kritische Integrationen sichern

Zentrale Erfolgsfaktoren:

Migration sofort starten, nicht bis September warten
Gründlich in Sandbox-Umgebungen testen
Auf Nutzerschulung und Governance fokussieren
Zusätzliche Sicherheitsschichten wie API Access Control erwägen

Frühe Vorbereitung, gründliche Tests und saubere Governance minimieren Störungen und stärken gleichzeitig die Sicherheitslage Ihrer Organisation deutlich.

FAQ

Warum blockiert Salesforce den OAuth 2.0 Device Flow?

Weil sich eine Device-Flow-Anfrage allein mit einer client_id starten lässt. Angreifer riefen Mitarbeitende an, gaben sich als IT aus und ließen eine bösartige Connected App genehmigen, deshalb wurde der Flow zurückgezogen statt nachgebessert.

Was ersetzt den Device Flow bei Salesforce?

Der Authorization Code Flow mit PKCE. Sie erzeugen einen code_verifier, senden dessen SHA256-Hash base64url-kodiert als code_challenge und liefern den ursprünglichen Verifier beim Tausch des Codes gegen Tokens zurück.

Woher kommt der Fehler "invalid code verifier" bei PKCE?

Meist von einem fehlenden code_challenge_method=S256 oder von Standard-Base64 dort, wo base64url gefordert ist. Base64url ersetzt + und / durch - und _ und lässt das Padding weg.

Funktionieren bestehende Connected-App-Autorisierungen weiter?

Autorisierungen über andere Flows bleiben gültig. Alles, was ein Nutzer über Device Flow genehmigt hat, wird unabhängig vom Alter blockiert, diese Integrationen müssen neu autorisiert werden.

Wie findet man nicht installierte Connected Apps?

Öffnen Sie im Setup den Bereich Connected Apps OAuth Usage. Ein "Install"-Button in der Spalte Actions kennzeichnet eine autorisierte, aber nicht installierte App, und genau diese Liste sollten Sie prüfen.