Flux OAuth Salesforce : choisir la bonne conception d'authentification

Comment choisir le bon flux OAuth Salesforce ? Faites passer un humain par l'Authorization Code Flow avec PKCE, reliez un job server-to-server au JWT Bearer Flow (ou au Client Credentials Flow) et ne revenez jamais à un nom d'utilisateur, un mot de passe et un security token sous prétexte que c'est plus rapide à mettre en place. Ce dernier raccourci a désormais une date limite. Salesforce a annoncé le retrait du flux username-password OAuth 2.0 pour les connected apps dans Spring '26, l'a d'abord inscrit pour une application avec le déploiement de Winter '27, puis l'a fixé à une date unique : le 20 février 2027. Cette date est la même pour chaque org de la plateforme et ne dépend pas du week-end de mise à niveau de votre instance, il n'y a donc aucune fenêtre échelonnée derrière laquelle se cacher. Les orgs créées à partir de Summer '23 bloquent déjà totalement ce flux. Avec une mauvaise conception, soit vous bloquez des intégrations légitimes hors de votre org, soit vous laissez un identifiant de longue durée là où un attaquant peut le trouver.

Comment choisir le bon flux OAuth Salesforce ?

Toute décision OAuth commence par une question : est-ce une personne qui autorise cette connexion, ou une machine ?

Si une personne est présente, faites-la passer par l'Authorization Code Flow avec PKCE (Proof Key for Code Exchange), que Salesforce documente comme le flux web server OAuth 2.0 avec l'extension PKCE et présente désormais comme le remplacement recommandé des connexions basées sur l'utilisateur. PKCE lie le code d'autorisation au client qui l'a demandé, si bien qu'un code intercepté en transit est inutile pour un attaquant. Préférez-le au Device Flow OAuth 2.0, que Salesforce est en train de retirer : l'éditeur a supprimé la prise en charge du Device Flow de la connected app Data Loader installée automatiquement le 2 septembre 2025, et Data Loader 64.1.0 a abandonné à la fois le Device Flow et le User-Agent Flow. Les deux étaient faciles à détourner car il suffisait de peu plus qu'un client ID pour les lancer, une cible de choix pour l'ingénierie sociale.

Si personne n'est présent, comme pour un job ETL nocturne ou un middleware qui envoie des enregistrements vers Salesforce, choisissez un flux server-to-server : le JWT Bearer Flow ou le Client Credentials Flow. Les deux permettent à un service backend de s'authentifier sans navigateur ni session à rediriger. Ce même choix sous-tend la plupart des modèles d'architecture d'intégration qui passent vraiment à l'échelle, car la conception de l'authentification doit survivre à chaque nouvelle tentative, timeout et rotation d'identifiants que ces modèles imposent.

JWT Bearer ou Client Credentials : quel flux server-to-server ?

Les deux flux authentifient l'application elle-même sans utilisateur, mais ils font des compromis différents sur la gestion des secrets.

• Le JWT Bearer Flow s'authentifie avec un certificat signé numériquement plutôt qu'avec un secret partagé. Aucun client secret ne traîne dans un fichier de configuration, l'assertion signée a une durée de vie courte, et faire tourner la clé revient à remplacer un certificat plutôt qu'à redéployer du code. Choisissez-le si vous voulez la posture la plus solide et pouvez gérer une clé privée.
• Le Client Credentials Flow échange une consumer key et un consumer secret contre un access token et s'exécute sous un utilisateur d'intégration désigné. Il est plus simple à configurer, mais le secret est un bearer credential : quiconque l'intercepte peut usurper l'intégration, il doit donc être stocké et renouvelé avec une vraie discipline.

Quel que soit votre choix, limitez strictement l'utilisateur d'exécution ou d'intégration avec un profil et des permission sets dédiés au lieu d'accorder un large accès admin par commodité. Un compte machine qui ne peut toucher que les objets dont il a besoin fait la différence entre un incident contenu et la compromission de toute l'org.

Connected Apps ou External Client Apps : qu'est-ce qui a changé pour 2026 ?

Salesforce scinde la connected app classique en deux types d'applications spécialisés, et le calendrier impose désormais la décision. Depuis Spring '26, Salesforce bloque la création de nouvelles connected apps via l'interface et l'API, l'installation de packages étant la seule exception, et recommande les external client apps à la place. Les connected apps existantes continuent de fonctionner pendant et après le changement : rien ne casse dans votre org le week-end de mise à niveau. Si vous devez vraiment créer une nouvelle connected app, le support Salesforce peut réactiver la création pour votre org pour l'instant, mais Salesforce a indiqué que cette possibilité sera supprimée dans une version ultérieure. C'est donc une passerelle, pas un plan à long terme.

Les external client apps sont la voie plus récente et recommandée pour tout système externe qui s'authentifie auprès de Salesforce via OAuth, y compris votre propre middleware, vos outils ETL et vos intégrations partenaires. Elles adoptent délibérément une position plus stricte : elles ne prennent en charge que les flux OAuth sécurisés et excluent totalement le flux username-password. Elles prennent aussi pleinement en charge la Metadata API et gardent les consumer secrets hors des composants packagés, ce qui les rend bien plus faciles à gérer via le contrôle de source et les pipelines CI/CD qu'une ancienne connected app.

La conclusion pratique pour une revue d'architecture : optez par défaut pour une external client app pour les nouvelles intégrations et réservez les connected apps aux cas natifs Salesforce qui en ont encore besoin, comme canvas et mobile publishing. Recourir par habitude à une ancienne connected app, c'est désormais se heurter à une restriction de création lors de votre prochain projet.

Quelle est la place des Named Credentials dans une conception d'intégration sécurisée ?

Les Named Credentials résolvent un autre problème : les callouts sortants de Salesforce vers des systèmes externes, pilotés par Apex ou Flow. Au lieu de coder en dur une URL d'endpoint et des détails OAuth dans une classe, vous enregistrez une fois un Named Credential et vous le référencez par son nom, par utilisateur ou pour toute l'org, et Salesforce gère l'échange et le renouvellement du token en arrière-plan.

C'est important pour la security review, car les identifiants disparaissent complètement du code. Que la négociation sous-jacente soit JWT Bearer ou Client Credentials, le secret ou la clé reste hors de votre code d'intégration, et la rotation se fait à un seul endroit au lieu de fouiller dans les classes Apex et les définitions de Flow. Quand vous connectez Salesforce à un lourd système de référence comme un ERP, c'est ce qui garde les modèles d'intégration Salesforce et SAP auditables plutôt qu'un tas de mots de passe intégrés.

Comment migrer d'anciennes intégrations username-password vers des flux OAuth modernes ?

La plupart des orgs que nous auditons ont encore au moins une intégration qui s'authentifie avec un nom d'utilisateur, un mot de passe et un security token, parfois depuis un script que personne ne se souvient d'avoir écrit. La date limite du 20 février 2027 a déjà glissé une fois depuis la liste d'application de Winter '27, alors considérez ce délai supplémentaire comme du temps de migration, pas comme un sursis. Aucune bannière d'avertissement n'apparaît dans l'interface : à la date limite, une intégration basée sur un mot de passe cesse simplement de recevoir un access token et renvoie une erreur d'authentification. Une migration structurée se présente ainsi :

• Inventoriez chaque utilisateur d'intégration et chaque profil avec accès API pour repérer où les connexions par mot de passe sont encore utilisées.
• Classez chaque intégration comme utilisateur présent ou server-to-server, puis associez-la à l'Authorization Code Flow avec PKCE, au JWT Bearer Flow ou au Client Credentials Flow.
• Enregistrez une External Client App dédiée par intégration plutôt que de partager une seule application entre des systèmes sans rapport.
• Placez les callouts sortants derrière des Named Credentials pour que les secrets restent hors de la base de code.
• Changez le mot de passe de l'ancien utilisateur d'intégration et révoquez son accès API une fois le trafic entièrement basculé.

Enchaînez la bascule intégration par intégration, en confirmant que chaque connexion s'authentifie dans une sandbox avant de toucher à l'identifiant dont dépend la production. La même conception d'authentification sous-tend aussi des modèles plus récents comme l'exécution d'actions CRM depuis un hub agentique, où une seule identité machine se déploie sur de nombreuses actions et où la fuite d'un secret serait d'autant plus dommageable.

C'est le type de travail que notre équipe de conseil réalise régulièrement. Si votre org exécute encore des intégrations basées sur des mots de passe, nous pouvons tracer le chemin de migration bien avant que le 20 février 2027 n'en fasse une urgence. Contactez-nous pour parler de votre configuration.

FAQ

Quand le flux OAuth username-password de Salesforce est-il retiré ?

Salesforce a déplacé le retrait du déploiement de Winter '27 vers une date unique, le 20 février 2027, qui s'applique à toutes les orgs en même temps au lieu de suivre le week-end de mise à niveau de chacune. Les orgs créées à partir de Summer '23 bloquent déjà ce flux. Migrez les intégrations concernées vers le flux web server avec PKCE, le JWT Bearer Flow ou le Client Credentials Flow avant cette date.

Puis-je encore créer une nouvelle Connected App en 2026 ?

Salesforce restreint la création de nouvelles connected apps depuis Spring '26 et recommande les external client apps à la place. Les connected apps existantes continuent de fonctionner, et vous pouvez demander une exception au support Salesforce si vous en avez vraiment besoin.

Quelle est la différence entre les flux JWT Bearer et Client Credentials ?

Ce sont deux flux server-to-server sans utilisateur présent. JWT Bearer s'authentifie avec un certificat signé et n'a aucun secret partagé susceptible de fuiter, tandis que Client Credentials échange une consumer key et un secret et s'exécute sous un utilisateur d'intégration désigné, ce qui est plus simple mais repose sur un bearer secret à stocker et à renouveler avec soin.

Les nouvelles intégrations doivent-elles utiliser des Connected Apps ou des External Client Apps ?

Optez par défaut pour les external client apps pour les nouvelles intégrations externes. Elles ne prennent en charge que les flux OAuth sécurisés, fonctionnent pleinement avec la Metadata API pour le CI/CD et sont la voie que Salesforce recommande désormais. Réservez les connected apps aux cas natifs Salesforce comme canvas et mobile publishing.

Les Named Credentials remplacent-ils les flux OAuth ?

Non. Les Named Credentials gèrent l'authentification des callouts sortants et peuvent utiliser en coulisses des flux OAuth comme JWT Bearer. Ils gardent les secrets hors d'Apex et de Flow sans remplacer le flux lui-même.