Skip to main content
Nous migrons activement les clients vers de nouveaux comportements pour toutes les dépréciations indiquées ci-dessous. Veuillez les examiner attentivement afin de vous assurer d’avoir pris toutes les mesures nécessaires pour éviter toute interruption de service. Vous pouvez également effectuer une recherche dans les journaux du tenant pour repérer toute erreur causée par l’utilisation de fonctionnalités dépréciées. Si vous avez des questions, consultez la Community ou créez un ticket dans notre Support Center. Pour en savoir plus, vous pouvez aussi consulter le Processus de migration.

​
Sécurité renforcée pour les applications tierces

Déprécié : 23 avril 2026 Fin de vie : 23 octobre 2026 Auth0 introduit des contrôles de sécurité renforcés pour les applications tierces, conformes aux pratiques exemplaires d’OAuth 2.1. À compter de la date de fin de vie, si vous créez une nouvelle application tierce au moyen de POST /api/v2/clients sans préciser third_party_security_mode, Auth0 appliquera automatiquement les contrôles de sécurité renforcés (strict). Ce changement touche uniquement les tenants qui utilisaient des applications tierces avant le 23 avril 2026 et n’a d’incidence que sur les applications nouvellement créées. Vos applications tierces existantes continueront de fonctionner comme aujourd’hui, sans aucune modification requise. Les contrôles renforcés offrent une autorisation d’API explicite, l’utilisation obligatoire de PKCE et un ensemble de fonctionnalités ciblé, conforme à OAuth 2.1 et aux pratiques exemplaires en matière de sécurité. Pour vous préparer à ce changement, consultez Passer à la sécurité renforcée pour les applications tierces pour vérifier si vous êtes concerné, configurer les permissions d’API par défaut et choisir votre approche de migration.

​
Gestion héritée des clients activés d’une connexion

Obsolète : 13 janvier 2026 Fin de vie : 13 juillet 2026 Le champ enabled_clients de l’objet de connexion de la Management API est obsolète dans les scénarios suivants : Comme solution de rechange à cette fonctionnalité obsolète, deux nouveaux points de terminaison de la Management API sont disponibles : Pour vous préparer à ce changement et vous assurer que vos intégrations continuent de fonctionner sans problème, consultez Migrer la gestion des clients activés vers des points de terminaison de connexion dédiés pour vérifier si vous êtes concerné et migrer vers les nouveaux points de terminaison.

​
Suites de chiffrement TLS 1.2 faibles

Obsolète : 10 décembre 2025 Fin de vie : 10 juin 2026 Après la date de fin de vie, nous exigerons l’utilisation de suites de chiffrement modernes pour se connecter aux endpoints de service Auth0 et aux applications web. Nous mettrons fin au soutien des suites de chiffrement TLS 1.2 qui n’offrent plus un niveau de sécurité suffisant pour protéger les communications réseau. Plus précisément, cette modification des suites de chiffrement prises en charge s’applique à :
  • les domaines par défaut des tenants de cloud public et privé; par exemple, [tenant_name].eu.auth0.com.
    • les domaines personnalisés des tenants de cloud public et privé.
    • les applications web liées au service, comme le Dashboard (manage.auth0.com) ou le Marketplace (marketplace.auth0.com).
    • le réseau de diffusion de contenu (CDN) d’Auth0. Pour en savoir plus, consultez Auth0 Public Cloud Service Endpoints.
La liste des suites de chiffrement abandonnées figure ci-dessous. Elle contient le code hexadécimal unique qui identifie chaque suite de chiffrement, ainsi que son nom IANA; pour les noms OpenSSL correspondants, suivez les liens vers ciphersuite.info. Suites de chiffrement TLS 1.2 dont la suppression est prévue :

​
Demande du nom de l’organisation sans SSO

Déprécié : 31 octobre 2025 Fin de vie : 1 mai 2026 Les flux de connexion lancés dans le contexte d’applications clientes associées à des utilisateurs professionnels (organization_usage=require) et configurées pour demander l’organisation au début du flux de connexion (organization_require_behavior=pre_login_prompt) tiendront compte d’une session authentifiée existante. Auparavant, le service demandait à l’utilisateur le nom de l’organisation, puis celui-ci devait ensuite se connecter. Par exemple, un utilisateur ayant un compte avec mot de passe devait saisir de nouveau ses identifiants, même si une session authentifiée était valide pour l’organisation sélectionnée.

​
Unconfirmed Login with Non-Verifiable Callback URI Redirects

Déprécié : 28 octobre 2025 Fin de vie : 28 avril 2026 Auth0 recommande, dans la mesure du possible, de passer à des URI de rappel sur HTTPS à l’aide de Android App Links et des Apple Universal Links pour toutes les applications natives qui utilisent le flux de code d’autorisation, afin de renforcer la sécurité et d’atténuer les risques d’usurpation d’application et d’attaques d’hameçonnage. De plus, Auth0 met en place une nouvelle invite de confirmation de connexion pour les requêtes d’authentification qui utilisent des schémas d’URI personnalisés ou des URI de rebouclage comme URI de rappel. Cette invite s’affichera dans les cas où une réponse était auparavant renvoyée sans interaction de l’utilisateur. Consultez Migrate to Non-Verifiable Callback URI End-User Confirmation pour en savoir plus.

​
Validation de l’audience pour l’authentification Private Key JWT

Deprecated : 6 octobre 2025 Fin de vie : 8 avril 2025 Lors de la validation des assertions JWT utilisées pour l’authentification de l’application cliente, Auth0 imposera des exigences plus strictes et n’acceptera que l’identifiant d’émetteur d’un tenant comme unique valeur de chaîne JSON dans la revendication aud (audience). La possibilité de fournir une revendication aud selon l’une ou l’autre des approches ci-dessous est déconseillée, et le service cessera de les prendre en charge après la date de fin de vie :
  • Un tableau JSON de chaînes, à condition que l’une des entrées contienne un identifiant d’émetteur valide ou une URL de point de terminaison valide pour le tenant et le point de terminaison visés auxquels le client s’authentifie.
  • Une seule chaîne JSON représentant une URL de point de terminaison valide pour le tenant et le point de terminaison visés auxquels le client s’authentifie.
Avant la date de fin de vie, les connexions d’entreprise OIDC configurées pour utiliser Private Key JWT dans les requêtes authentifiées envoyées au fournisseur d’identité en amont pourront utiliser l’identifiant d’émetteur applicable, représenté sous forme de chaîne JSON dans la revendication “aud” incluse dans les assertions JWT.

​
Attributs étendus dans les connexions Azure Active Directory (v1) Identity API

Déprécié : 18 juin 2025 Fin de vie : 1er septembre 2025 En raison de la dépréciation d’Azure AD Graph et de son retrait prévu, Auth0 ne prendra plus en charge l’activation des options liées aux attributs étendus dans les connexions Microsoft Azure AD (strategy=waad) configurées pour utiliser l’Identity API Azure Active Directory (v1). Si vous avez reçu une notification par courriel, un ou plusieurs de vos tenants pourraient avoir une connexion Microsoft Azure AD qui cible l’Identity API Azure Active Directory (v1), qui est configurée pour obtenir des attributs étendus et qui pourrait donc être touchée. Vous devez examiner les tenants concernés. Pour les connexions qui reposent sur la fonctionnalité dépréciée, vous devez soit :
  • Mettre à jour les connexions pour qu’elles ciblent Microsoft Identity Platform (v2), afin que les endpoints Microsoft Graph soient utilisés à la place d’Azure AD Graph déprécié lors de la récupération des informations sur les attributs étendus.
  • Désactiver toutes les options liées aux attributs étendus.
Bien que la deuxième option ci-dessus vous permette de conserver des connexions qui ciblent l’Identity API Azure Active Directory (v1) si les informations étendues ne sont pas nécessaires, il est généralement recommandé de cibler Microsoft Identity Platform (v2). Pour en savoir plus, consultez Connectez votre application à Microsoft Azure Active Directory. Pour plus d’information sur la dépréciation, communiquez avec le soutien Auth0.

​
Extension Real-Time Webtask Logs

Obsolète : 18 juin 2025 Fin de vie : 16 septembre 2025 L’extension Real-time Webtask Logs est obsolète et sa fin de vie (EOL) est prévue après le 16 septembre 2025.  En remplacement, la fonctionnalité Actions Real-time Logs est offerte directement dans l’Auth0 Dashboard. L’extension ne sera plus offerte pour les nouvelles installations, mais les tenants pour lesquels l’extension est déjà installée conserveront l’accès jusqu’à la date de fin de vie prévue.

​
Supprimer l’accès à certaines propriétés de la requête de l’événement dans Actions

Obsolète : 18 juin 2025 Fin de vie : 16 septembre 2025 Auth0 limitera l’accès à d’autres noms de propriétés dans les objets event.request.query et event.request.body lors de l’exécution des Actions pour les déclencheurs post-login et credentials-exchange. Seuls les tenants identifiés comme utilisant Actions pour référencer des propriétés de la requête visées par cette restriction conserveront cet accès jusqu’au 16 septembre 2025. Le service limitera les noms de propriétés suivants dans les objets liés à la requête :
  • auth_session
  • authn_response
  • client_secret
  • client_assertion
  • refresh_token

​
Plusieurs Actions pour les déclencheurs de fournisseurs de téléphone et de courriel personnalisés

Obsolète : 16 juin 2025 Fin de vie : 16 décembre 2025 Auth0 instaure une limite maximale d’une seule Action pour les Actions associées aux déclencheurs suivants :
  • custom-phone-provider
  • custom-email-provider
Cette limite s’applique au point de terminaison Create an Action de la Management API (POST - /api/v2/actions/actions). Une fois cette nouvelle limite en vigueur pour un tenant donné, toute tentative de créer plusieurs actions pour ces déclencheurs échouera.

​
Flux de courriel de déblocage non personnalisable de la Brute-force Protection

Déprécié : 9 juin 2025 Fin de vie : 9 décembre 2025 Une version mise à jour du flux de déblocage par courriel pour la Brute-force Protection est offerte. Elle prend en charge la personnalisation et la localisation au moyen de Universal Login, et améliore l’expérience lorsque des analyseurs de sécurité des courriels traitent le courriel de déblocage.

​
Champ fromSandbox dans les réponses d’Error de Authentication API

Obsolète : 11 juin 2025 Fin de vie : 11 décembre 2025 Les réponses d’Error de Authentication API ne renverront plus le champ fromSandbox pour les flux nécessitant l’appel d’un script de base de données personnalisé. Par exemple, une réponse d’Error d’API dans le contexte du flux d’inscription d’un utilisateur final pour une connexion de base de données personnalisée ne renverra plus ce champ. Déprécié : 13 mai 2025 Fin de vie : 13 novembre 2025 Lorsque vous mettez à jour l’hôte, le port ou le nom d’utilisateur d’un fournisseur de courriel SMTP au moyen d’une requête PATCH vers le endpoint /api/v2/emails/provider, vous devrez peut-être préciser un mot de passe pour le champ credentials.smtp_pass. L’objet d’identifiants d’un fournisseur de courriel SMTP prend en charge les champs suivants :
  • credentials.smtp_pass : mot de passe du fournisseur de courriel SMTP
  • credentials.smtp_host : hôte du fournisseur de courriel SMTP
  • credentials.smtp_port : port du fournisseur de courriel SMTP
  • credentials.smtp_user : nom d’utilisateur du fournisseur de courriel SMTP
Auth0 exige une valeur explicite pour le champ credentials.smtp_pass dans les cas suivants :
  • Lorsque vous mettez à jour les champs credentials.smtp_host, credentials.smtp_port ou credentials.smtp_user d’un fournisseur de courriel SMTP avec une valeur différente de la valeur existante, ou lorsque vous ne mettez à jour qu’un sous-ensemble de ces trois champs.
Auth0 n’exige pas de valeur explicite pour le champ credentials.smtp_pass dans les cas suivants :
  • Lorsque vous mettez à jour un fournisseur de courriel SMTP et que le corps de la requête comprend les mêmes valeurs que les valeurs existantes pour les champs credentials.smtp_host, credentials.smtp_port et credentials.smtp_user.

​
Pagination par décalage sans restriction dans la Management API des connexions

Deprecated : 29 avril 2025 Fin de vie : 27 octobre 2025 Le point de terminaison get all connections de la Management API qui utilise la pagination par décalage ne permettra plus de récupérer des résultats paginés au-delà des 1000 premières connexions. Par exemple, le service renverra une réponse d’erreur si page=30&per_page=50 ou page=15&per_page=100 est utilisé. Dans les deux cas, le produit du nombre d’enregistrements demandés par page et de l’indice de page demandé plus un (pour tenir compte du fait que l’indice de page commence à zéro) fait en sorte que la requête dépasse les 1000 premières connexions. Comme indiqué ci-dessus, avec une taille de page de 50, le dernier indice de page que vous pouvez demander sans erreur est 19 (page=19&per_page=50), et avec la taille de page maximale de 100, vous pouvez aller jusqu’à l’indice de page 9 (page=9&per_page=100). Les conditions qui dépassent cette limite déclenchent l’erreur, même si le tenant associé à la requête compte moins de 1000 connexions.

​
Runtimes d’extensibilité Node.js 12 et 16

Obsolète : 10 février 2025 Fin de vie : 15 août 2025 Les runtimes d’extensibilité Node.js 12 et 16 deviendront progressivement indisponibles dans l’ensemble des tenants Auth0. Une fois retirées, toutes les intégrations d’extensibilité, comme Actions, Rules, Hooks, Custom Database Connections et Custom Social Connections, devront s’exécuter sur Node 22. Pour obtenir des ressources techniques sur la migration vers Node 22, consultez Migrer de Node 12 et 16 vers Node 18 et Migrer de Node 18 vers Node 22.

​
Nouveaux scopes de la Management API requis pour les options de connexion

Déprécié : 24 octobre 2024 Fin de vie : 8 juillet 2025 Les requêtes adressées aux points de terminaison de la Management API suivants exigeront le scope read:connections_options pour afficher le champ options : Les requêtes adressées aux points de terminaison de la Management API suivants exigeront le scope update:connections_options pour modifier le champ options :

​
Dépréciation de Rules et Hooks

Déprécié : 16 mai 2023 Transition en lecture seule : 18 novembre 2024 Fin de vie : 18 novembre 2026 Après le 18 novembre 2026, Rules et Hooks ne seront plus exécutés et seront supprimés. Le 18 novembre 2024, les Rules et Hooks actifs continueront de s’exécuter, mais passeront en mode lecture seule. Auth0 a reporté à plus tard la suppression de la fonctionnalité Rules et Hooks. Les Rules et Hooks en lecture seule peuvent être activés et désactivés, et leurs valeurs de configuration ou secrets respectifs peuvent être modifiés, mais leur code source ne peut pas être modifié à partir du Dashboard ou de la Management API, y compris au moyen d’outils de CI/CD comme Terraform et Auth0 Deploy CLI. Si vous ne pouvez pas migrer vers Actions avant la transition en lecture seule, assurez-vous qu’aucun processus CI/CD automatisé que vous avez configuré pour déployer des changements de configuration du tenant ne tente d’effectuer des opérations de gestion non prises en charge sur Rules et Hooks. Pour en savoir plus, consultez passer de Rules à Actions et passer de Hooks à Actions.

​
Activer l’UI conforme aux WCAG 2.2 AA pour Universal Login

Déprécié : 23 août 2024 Fin de vie : 31 juillet 2025 Auth0 supprimera la possibilité d’utiliser l’UI Legacy non conforme pour . La nouvelle version conforme aux WCAG garantit que les utilisateurs finaux, y compris ceux qui utilisent des technologies d’assistance, peuvent accéder au produit ou au service d’un client et interagir avec celui-ci. Consultez notre documentation sur l’accessibilité d’Universal Login pour en savoir plus.

​
En savoir plus