Vos identifiants ne se contentent plus de dire que vous avez passé un second facteur : ils précisent désormais lequel. Toute la subtilité tient dans deux mécanismes discrets, AuthNContext et AMR (Authentication Methods References), qui décrivent, dans les assertions SAML et les jetons OpenID Connect, la manière exacte dont une authentification a été réalisée.
Le sujet est sorti de l’ombre avec les changements poussés cet été par Microsoft Entra ID et Salesforce. Les applications peuvent maintenant s’appuyer sur des valeurs AMR et ACR (AuthnContextClassRef) pour distinguer un simple mot de passe, une MFA classique ou une MFA résistante au phishing. Côté SSO, Salesforce s’appuie sur ces signaux transmis par l’IdP pour classer les connexions et appliquer ses règles d’accès.
Points clés
- Salesforce classe désormais les connexions en trois niveaux : Phishing-Resistant MFA, Standard MFA et Weak MFA / No MFA.
- Les signaux AMR et AuthnContext (SAML/OIDC) décrivent quels facteurs ont réellement servi lors de l’authentification.
- Microsoft Entra ID ajoute automatiquement les claims amr et acr à ses jetons SAML 2.0 et OIDC v2.0 depuis le 29 juin 2026.
- Les comptes d’administration Salesforce doivent utiliser une MFA résistante au phishing, excluant SMS, push et TOTP classiques.
Des jetons qui transportent le détail de l’authentification
AMR et AuthnContext indiquent, dans un format standardisé, quels facteurs ont servi lors de la connexion. Dans SAML, l’info se loge dans AuthnContextClassRef. Dans OpenID Connect, elle voyage via le jeton d’identité. Microsoft documente des valeurs comme mfa, multipleauthn ou wiaormfa, tandis que Salesforce évalue ces signaux pour trancher entre ses différents niveaux de MFA, dont la fameuse catégorie phishing-resistant MFA.
La documentation de Salesforce, mise à jour en juin 2026, range les connexions en trois catégories : Phishing-Resistant MFA, Standard MFA et Weak MFA / No MFA. Pour les accès SSO, l’éditeur exige explicitement que l’IdP lui transmette des signaux ACR ou AMR dans la réponse SAML ou le jeton OIDC.
Un détail a fait tiquer les équipes identité : dans certains montages SSO, l’IdP ne renvoyait pas assez d’informations pour prouver qu’un utilisateur avait bien dégainé une clé de sécurité, une passkey ou un autre facteur résistant au phishing. Des publications de spécialistes de Microsoft Entra confirment que l’éditeur ajoute automatiquement les claims amr et acr dans ses jetons pour les applications SAML 2.0 et OIDC v2.0, à partir du 29 juin 2026.
Salesforce serre la vis en juillet 2026
Le mouvement s’inscrit dans un durcissement progressif. Salesforce impose la MFA à l’ensemble de ses employés et ajoute des règles plus strictes pour les rôles privilégiés. Les comptes d’administration doivent utiliser une MFA résistante au phishing, ce qui exclut d’office les codes SMS, les notifications push et les applications TOTP classiques dans les cas visés.
Les sources publiques situent le déploiement sur l’été 2026, avec une entrée en production pour les administrateurs dès le 1er juillet dans certains cas, puis un élargissement à d’autres populations plus tard dans le mois. Salesforce le répète : pour le SSO, ce ne sont pas les méthodes de l’IdP qui comptent, mais les signaux réellement transmis dans l’assertion ou le jeton.
Résultat, les équipes IAM doivent vérifier que leur fournisseur d’identité sait exposer le bon niveau de preuve. Sans AMR ou AuthnContext correctement renseigné, une connexion peut être classée trop faiblement et se voir refuser l’accès aux fonctions sensibles. L’utilisateur a beau brandir sa clé FIDO, si le jeton reste muet, c’est comme s’il ne l’avait jamais sortie.
Ce que les administrateurs doivent vérifier
- La présence des claims amr et acr dans les réponses SAML ou les jetons OIDC.
- La correspondance entre la méthode réellement utilisée et le niveau de MFA attendu par l’application.
- Le comportement du SSO pour les comptes administrateurs et les rôles à privilèges élevés.
- Les politiques Conditional Access côté Microsoft Entra ID, si l’IdP sert à l’authentification Salesforce.
Le débat n’a rien de théorique : il détermine si un service SaaS accepte une connexion, la classe en MFA standard ou la juge assez solide pour un compte à hauts privilèges. AMR et AuthnContext deviennent des pièces maîtresses du contrôle d’accès, à égalité avec la méthode d’authentification elle-même.
