Tekunda Team

Mis à jour il y a 3 mois

Authentification Salesforce : guide complet de migration

Évolution de l'authentification Salesforce, votre guide complet de migration

En septembre 2025, Salesforce met en place des changements majeurs de sécurité pour les Connected Apps, avec un impact direct sur l'authentification de vos applications. Deux changements importants arrivent :

Le OAuth 2.0 Device Flow sera bloqué.

Les Connected Apps non installées ne seront plus accessibles à la plupart des utilisateurs.

Cet article explique la migration depuis Device Login flow vers Connected App OAuth2 Flow avec PKCE, pourquoi ce changement compte et comment se préparer sereinement.

Pourquoi Salesforce bloque Device Flow

Le Device Flow (RFC8628) présente une vulnérabilité connue : il peut être lancé avec un simple client_id. Un acteur malveillant peut l'exploiter dans des attaques de social engineering pour pousser des utilisateurs à approuver des applications non fiables.

Impact réel : De récentes compromissions très médiatisées chez KLM Airfrance, Adidas, Google, Qantas et Allianz Life ont été menées par des groupes comme UNC6040/ShinyHunters avec ce vecteur précis. Les attaquants ont utilisé le social engineering, notamment des appels se faisant passer pour l'IT, afin de faire autoriser des Connected Apps malveillantes via Device Flow.

Salesforce a confirmé que cette vulnérabilité a été exploitée dans des environnements de production, ce qui fait de la dépréciation une nécessité de sécurité plutôt qu'une simple mise à niveau technique.

Passer à Connected App OAuth2 Flow avec PKCE

Le remplacement sécurisé est PKCE (Proof Key for Code Exchange), une amélioration de Authorization Code Flow qui empêche l'interception du code d'autorisation.

Étape 1 : générer les paramètres PKCE

Créez un code_verifier, une chaîne aléatoire cryptographiquement sûre de 43 à 128 caractères.

Hachez-la avec SHA256 et encodez-la en base64url → code_challenge.

Important : utilisez l'encodage base64url, pas base64 standard. Cela remplace + par -, / par _ et retire les caractères de padding = pour la sécurité URL.

Étape 2 : construire l'Authorization URL

Assurez-vous d'inclure le paramètre critique nécessaire à PKCE :

code_challenge_method=S256

Exemple :

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

Étape 3 : échanger l'Authorization Code contre des tokens

Renvoyez le code et le code_verifier à 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

Étape 4 : mettre à jour les permissions

Salesforce ajoute de nouvelles permissions avec des règles selon la configuration de votre org :

Si API Access Control est DÉSACTIVÉ, cas le plus courant :

Les utilisateurs peuvent accéder aux applications non installées avec l'une des permissions :

Approve Uninstalled Connected Apps (nouveau dans Summer '25), recommandé dans la plupart des cas
Use Any API Client, permission plus large, à utiliser avec prudence

Si API Access Control est ACTIVÉ :

Seule la permission Use Any API Client fonctionnera pour accéder aux applications non installées.

Changements spécifiques à Data Loader

Date limite critique : 2 septembre 2025, la prise en charge OAuth Device Flow prend fin dans Data Loader.

Actions requises :

Changer de méthode d'authentification avant le 2 septembre :
- Password authentication (username + password + security token)
- OAuth Web Server Flow (recommandé)
Mettre à jour Data Loader, Salesforce publiera une nouvelle version avant le 2 septembre avec Device Flow totalement retiré
Note : l'usage command line avec mots de passe chiffrés n'est pas affecté

Défis courants de migration

Erreurs PKCE ("invalid code verifier") : généralement causées par l'absence de code_challenge_method=S256 ou un encodage base64url incorrect.

Accès utilisateur bloqué après septembre : corrigez en assignant la permission appropriée selon le statut API Access Control.

Échecs de connexion Data Loader : migrez la méthode d'authentification avant le 2 septembre 2025.

Configuration Connected App incorrecte : lors de l'installation, définissez "Permitted Users" sur "Admin approved users are pre-authorized" pour un meilleur contrôle de sécurité.

Calendrier et plan d'action

Actions immédiates (avant le 2 septembre 2025)

Auditer les Connected Apps :

Allez dans Setup → Connected Apps OAuth Usage
Cherchez les boutons "Install" dans la colonne Actions, signe d'applications non installées

Identifier l'usage de Device Flow :

Concentrez-vous sur les utilisateurs Data Loader
Vérifiez toute application custom utilisant Device Flow

Planifier l'implémentation PKCE :

Revoir les OAuth flows actuels
Préparer les ressources de développement pour la migration PKCE

Phase de migration (août–septembre 2025)

Implémenter un OAuth flow avec PKCE :

Assurer un encodage base64url correct
Inclure le paramètre code_challenge_method=S256
Tester les flows d'autorisation et d'échange de tokens

Tester dans Salesforce sandbox :

Valider l'implémentation PKCE
Tester les assignations de permissions utilisateurs
Vérifier les alternatives Data Loader

Configurer correctement les Connected Apps :

Installer les applications non installées de confiance avec le bouton "Install"
Définir "Permitted Users" sur "Admin approved users are pre-authorized"
Assigner l'accès via Permission Sets selon le principe du moindre privilège

Préparer la migration Data Loader :

Former les utilisateurs aux nouvelles méthodes d'authentification
Mettre à jour la documentation et les procédures
Tester password authentication ou Web Server Flow

Après migration (après septembre 2025)

Surveiller les logs d'authentification :

Surveiller les tentatives d'authentification échouées
Suivre les patterns d'usage Connected App
Surveiller les incidents de sécurité

Assurer le support utilisateur :

Traiter rapidement les problèmes d'accès
Aider les utilisateurs avec les nouvelles méthodes d'authentification
Documenter les étapes de troubleshooting courantes

Revoir les security policies chaque trimestre :

Auditer régulièrement les permissions Connected App
Revoir l'accès utilisateur aux intégrations sensibles
Envisager API Access Control pour une sécurité renforcée

Recommandations de sécurité renforcée

Optionnel mais recommandé : activer API Access Control

Contactez Salesforce Support pour activer cette fonction, qui fournit :

Accès Connected App basé sur allowlist
Contrôle granulaire des applications accessibles aux utilisateurs
Blocage proactif des applications non autorisées

L'éducation utilisateur est critique

Former les utilisateurs à reconnaître les tentatives de social engineering
Établir des procédures claires pour demander l'accès Connected App
Communiquer régulièrement les security best practices
Rappeler aux utilisateurs de ne jamais approuver d'applications inconnues

Framework de gouvernance

Définir un ownership clair pour chaque Connected App
Créer des processus d'approbation pour les nouvelles intégrations
Mettre en place des access reviews régulières
Impliquer les équipes sécurité dans les politiques Connected App

Exception importante à noter

Autorisations existantes : les utilisateurs ayant déjà autorisé des Connected Apps peuvent continuer à les utiliser après septembre 2025, SAUF si ces apps ont été autorisées via Device Flow. Toutes les autorisations Device Flow seront immédiatement bloquées, quel que soit l'usage précédent.

Conclusion

La dépréciation du Device Flow par Salesforce n'est pas qu'une mise à niveau technique. C'est une réponse de sécurité critique à des attaques réelles ayant compromis de grandes organisations. Les incidents récents chez des entreprises connues démontrent l'urgence de ces améliorations.

En migrant vers Connected App OAuth2 Flow avec PKCE et en configurant correctement les permissions, les organisations peuvent :

Se protéger contre les attaques d'interception d'authorization code
Maintenir la conformité avec les exigences de sécurité Salesforce
Réduire la surface d'attaque disponible pour le social engineering
Assurer la continuité business des intégrations critiques

Facteurs clés de succès :

Démarrer la migration immédiatement, ne pas attendre septembre
Tester rigoureusement dans les environnements sandbox
Mettre l'accent sur l'éducation utilisateur et la gouvernance
Envisager des couches de sécurité supplémentaires comme API Access Control

Une préparation précoce, des tests complets et une gouvernance adaptée minimisent les perturbations tout en renforçant nettement la posture de sécurité de votre organisation.