Migrations passées

Ce sont des migrations qui ont déjà été activées pour tous les clients. Si vous avez des questions, créez un ticket dans notre Centre d’assistance.

Déconseillé : 5 juin 2024

Fin de vie : 5 août 2024

L’accès pour consulter les Tickets d’abonnement dans le Centre d’assistance Auth0 change le 5 août 2024. Pour continuer à pouvoir consulter et gérer tous les tickets d’assistance créés par tous les utilisateurs d’un locataire, le nouveau rôle Accès au soutien élevé est requis.

Déconseillé : 7 décembre 2023

Fin de vie : 5 février 2024

Les liens de réinitialisation du mot de passe et de vérification par courriel ne seront plus enregistrés dans les journaux des locataires. Ces liens peuvent être récupérés à partir de la réponse à la demande de Management API de réinitialisation du mot de passe ou de la vérification par courriel.

‌‌Déconseillé :‌‌ 5 septembre 2023 (nuage public), 21 novembre 2023 (nuage privé)

Fin de vie : 21 février 2024

Avec ce changement, nous imposerons une durée de vie maximale de 1 heure pour les flux de connexion basés sur des redirections. Les flux de connexion qui prennent plus d’une heure expireront en connexion universelle et classique. Après expiration, les actions ultérieures du navigateur de l’utilisateur final (p. ex., saisie d’un courriel/mot de passe, redirection vers Actions/Règles, etc.) entraîneront :

• une redirection vers le chemin de connexion par défaut de l’application pour réinitialiser le flux en tant que nouvelle transaction de connexion, ou

• une page d’erreur si le chemin de connexion par défaut n’est pas configuré.

Déconseillé : 12 juillet 2023

Fin de vie : 17 janvier 2024

Nous améliorons l’évaluation de la permission lors de l’échange de jetons d’actualisation pour nous assurer que les permissions non enregistrées ne peuvent pas être demandées. Les valeurs de permission personnalisées non enregistrées par rapport à la valeur pub ou audience (pour une API enregistrée dans votre locataire) sont considérées comme des permissions non enregistrées.

Avec ce changement, l’évaluation de la permission de l’API inclura toutes les permissions personnalisées demandées lors de l’authentification de l’utilisateur ou injectées par l’extensibilité, telles que les règles. Cette évaluation validera que toutes les permissions sont enregistrées, en renvoyant une erreur si certaines ne le sont pas.

Déconseillé : 27 avril 2023

Fin de vie : 30 juin 2023 (express-oauth2-bearer), 27 octobre 2023 (angular-auth0 et auth0-cordova)

On déconseille les référentiels suivants :

• express-oauth2-bearer | guide de migration‌‌

• angular-auth0 | guide de migration‌‌

• auth0-cordova | guide de migration‌‌

Ces bibliothèques ne seront plus prises en charge. Veuillez supprimer ces bibliothèques des projets actifs avant ces dates.

Si vous avez des questions ou des préoccupations, n’hésitez pas à nous contacter sur GitHub.

Migration cible : 11 septembre 2023

Dans le cadre de notre mission de prendre en charge chaque version future de la prise en charge à long terme (LTS) Node.js par le biais d’Actions, et d’être en ligne avec la communauté des développeurs Node JS, nous publions Node 18 alors que Node 16 est toujours en LTS active. Nous exhortons tous les clients à passer aujourd’hui au Node 18 et à tirer le meilleur parti de sa LTS. N’oubliez pas que si la LTS de Node 16 se poursuit jusqu’en septembre, son utilisation peut comporter certains risques après la conclusion de la LTS et nous vous recommandons de passer au Node 18.

Node.js 18 est désormais généralement disponible sur l’ensemble de notre suite d’offres d’extensibilité. Cela inclut les actions, les règles, les appels, les scripts de base de données et les connexions personnalisées avec les réseaux sociaux. Nous encourageons vivement tout le monde à mettre à jour vers la version de Node 18 avant le 11 septembre 2023 pour adhérer aux meilleures pratiques de sécurité du code.

Déconseillé : 21 décembre 2022

Fin de vie : 21 juin 2023

Après le 21 juin 2023, Auth0 ne prendra plus en charge l’exécution de .NET et de C# à partir de Node.js dans les fonctionnalités d’extensibilité. Auth0 prenait précédemment en charge un sous-ensemble du langage C# pour écrire du code d’extensibilité pour les règles, les crochets et les scripts de base de données personnalisés au moyen d’un module Node.js appelé edge.js.

Il est déconseillé de prendre en charge l’exécution de .NET et de C# à partir de Node.js dans les fonctionnalités d’extensibilité, car il est essentiel de maintenir une plateforme performante et sécurisée pour l’exécution d’un code non fiable. Ce changement nous permettra de continuer à améliorer nos offres d’extensibilité de prochaine génération. Pour en savoir plus, consultez Migration depuis les fonctionnalités d’extensibilité de edge.js.

Déconseillé : 21 décembre 2022

Fin de vie : 21 juin 2023

Depuis le 31 juillet 2023, Auth0 ne prend plus en charge le module complémentaire auth0-claims-provider pour Sharepoint 2010/2013.

Après le 21 juin 2023, Auth0 ne prendra plus en charge l’exécution de bases de données Oracle à partir de Node.js dans les fonctionnalités d’extensibilité. Auth0 prenait précédemment en charge la connexion aux bases de données Oracle à partir du code d’extensibilité pour les règles, les crochets et les scripts de base de données personnalisés au moyen d’un module Node.js appelé oracledb.

Il est déconseillé de prendre en charge la connexion aux bases de données Oracle depuis Node.js dans Extensibilité, car il est essentiel de maintenir une plateforme performante et sécurisée pour l’exécution d’un code non fiable. Ce changement nous permettra de continuer à améliorer nos offres d’extensibilité de prochaine génération.

Pour en savoir plus, consultez Migration depuis les fonctionnalités d’extensibilité oracledb.

Déconseillé : 31 janvier 2023

Fin de vie : 31 juillet 2023

Auth0 ne prendra plus en charge le module complémentaire auth0-claims-provider pour Sharepoint 2010/2013 après le 31 juillet 2023. Sans ce module complémentaire, vous ne pourrez pas utiliser le « Sélecteur d’utilisateurs Sharepoint » avec des connexions Auth0 pour attribuer des autorisations aux utilisateurs de Sharepoint 2010/2013.

Vous devez retirer toute intégration avec le module complémentaire auth0-claims-provider avant le 31 juillet 2023. À partir de cette date, toutes les intégrations réalisées avec le module complémentaire auth0-claims-provider ne fonctionneront plus correctement et risquent d’avoir une incidence sur les utilisateurs de vos applications.

Déconseillé : 9 novembre 2022

Fin de vie : 9 mai 2023

Pour améliorer les performances, le point de terminaison Get Role Users de Management API ne renverra plus de 1000 résultats au total que si la méthode de pagination du point de contrôle est utilisée. Cette méthode de pagination est optimisée pour prendre en charge de grandes quantités de résultats. La méthode de pagination basée sur le décalage sera plafonnée à 1000 résultats.

Pour des détails sur la mise en œuvre des deux méthodes de pagination, consultez Documentation de Management API pour le point de terminaison Get Role Users.

‌‌Déconseillé :‌‌ 28 juillet 2022 (nuage public), 31 août 2022 (nuage privé)

‌‌Fin de vie :‌‌ 30 janvier 2023 (nuage public), 18 avril 2023 (nuage privé)

À compter du 30 janvier 2023 dans le nuage public et du 18 avril 2023 dans le nuage privé, Auth0 permettra l’ajout de demandes personnalisées et sans espace de noms aux jetons JWT à l’aide d’Auth0 Actions et dans les réponses du point de terminaison /userinfo de Authentication API. Auparavant, Auth0 autorisait les demandes avec espace de noms sur les jetons d’accès et d’ID au moyen d’un code d’extensibilité (Règles / Crochets / Actions). La migration vers des demandes personnalisées permet d’ajouter des demandes personnalisées privées et sans espace de noms et des demandes de profil utilisateur OIDC aux jetons d’accès; les jetons d’ID prennent actuellement en charge les demandes de profil utilisateur et prendront également en charge les demandes personnalisées privées et sans espace de noms. Ces demandes seront également ajoutées à la réponse /userinfo Auth0. Pour commencer la migration, lisez le Guide de migration des demandes personnalisées.

Si votre locataire exécute du code d’extensibilité (Règles / Crochets / Actions) qui tente de définir des demandes personnalisées, sans espace de noms, qui sont ignorées jusqu’à cette obsolescence, ces demandes commenceront alors à apparaître dans les jetons et la réponse /userinfo. Nous vous recommandons de revoir votre configuration et les journaux Auth0.

Avec l’ajout des demandes privées sans espaces de noms, Auth0 impose les restrictions suivantes, qui pourraient potentiellement affecter votre locataire :‌‌

• Auth0 a restreint la charge utile des demandes personnalisées (100 Ko max.).

• Auth0 a restreint la personnalisation/modification des demandes OPENID standard ou des demandes utilisées par Auth0 en interne.

• À l’avenir, Auth0 pourra restreindre l’utilisation d’autres demandes non incluses dans la liste ci-dessus. Dans ces cas, les clients seront informés dans un délai raisonnable pour migrer.

• Auth0 a restreint la création de demandes personnalisées privées et sans espace de noms pour les jetons d’accès avec un public Auth0, à l’exception du point de terminaison /userinfo.

• Seules les demandes de profil utilisateur l’OIDC précises peuvent être ajoutées aux jetons d’accès.

• Auth0 a restreint la création des demandes personnalisées commençant par le caractère $.

Pour en savoir plus sur les demandes personnalisées, consultez Créer des demandes personnalisées.

Déconseillé : 13 juin 2022

Fin de vie : 31 janvier 2023

Nous apportons des améliorations à l’infrastructure sous-jacente qui prend en charge le nuage privé Auth0 en introduisant un empilement technologique moderne basé sur Kubernetes, ainsi que des mises à niveau de la base de données. Nous travaillons actuellement avec tous les clients du nuage privé Auth0 pour planifier la mise à niveau de leur déploiement de nuage privé vers le nouvel empilement d’infrastructure au cours de cette année, et nous abandonnerons l’ancien empilement d’ici le 31 janvier 2023.

En outre, 2205 (version de mai 2022) est la dernière version officielle de l’ancienne plateforme de nuage privé. Tous les bogues et vulnérabilités de sécurité seront évalués et corrigés dans les correctifs diffusés si nécessaire. Avant la mise à niveau vers le nouvel empilement d’infrastructure, les environnements devront être mis à jour vers la version minimale compatible pour soutenir les efforts de mise à niveau.

Veuillez contacter votre responsable de compte technique pour toute question.

‌‌Déconseillé :‌‌ 4 mai 2022 (nuage public), 9 juin 2022 (nuage privé) (version nuage privé 2205)

‌‌Fin de vie :‌‌ 2 mai 2023 (nuage public), 6 janvier 2023 (nuage privé)

Depuis le 4 mai 2022 (nuage public) et le 9 juin 2022 (nuage privé), les extensions de journal Auth0 suivantes sont déconseillées :‌‌

• Lens de rappel HTTP de Authentication API Auth0

• Liens de rappel HTTP de l’Auth0 Management API

• Logs to Cloudwatch (Journaux vers CloudWatch)

• Logs to Logentries (Journaux vers Logentries)

• Logs to Loggly (Journaux vers Loggly)

• Logs to Logstash (Journaux vers Logstash)

• Logs to Papertrail (Journaux vers Papertrail)

• Logs to Splunk (Journaux vers Splunk)

• Logs to Sumo Logic (Journaux vers Sumo Logic)

‌‌Déconseillé :‌‌ 2 novembre 2022 (nuage public), 21 décembre 2022 (nuage privé)

‌‌Fin de vie :‌‌ 2 mai 2023 (nuage public), 31 mai 2023 (nuage privé)

Depuis le 2 novembre 2022 (nuage public) et le 9 juin 2022 (nuage privé), les extensions de journal Auth0 suivantes sont déconseillées :‌‌

• Logs to Segment (Journaux vers Segment)

• Logs to Mixpanel (Journaux vers Mixpanel)

• Logs to AppInsights (Journaux vers AppInsights)

• Logs to Azure Blob Storage (Journaux vers Azure Blob Storage)

Toutes les extensions de journal répertoriées ci-dessus sont désormais obsolètes. Vous pouvez configurer des fonctionnalités équivalentes à l’aide de flux d’événements de journal ou d’intégrations sur Auth0 Marketplace. Le 2 novembre 2022 dans le nuage public et le 21 décembre 2022 dans le nuage privé, Auth0 ne prendra plus en charge les extensions de journal installées de la liste ci-dessus. Pour plus d’informations, consultez Migrer à partir des extensions de journal.

Déconseillé : 9 décembre 2021 et décembre 2021 (version nuage privé 2112.2)

‌‌Fin de vie :‌‌ 9 juin 2022 et 9 septembre 2022 (nuage privé)

À compter du 9 juin 2022 dans le nuage public et du 9 septembre 2022 dans le nuage privé, Auth0 augmentera la sécurité des appels d’API en ajoutant une étape de validation des noms d’hôtes des locataires au processus d’identification de Authentication API. Lorsqu’un appel est effectué, Authentication API validera l’identifiant d’entité (p. ex. : client_id) du locataire demandeur ainsi que le nom du locataire dans le domaine de l’URL. Le locataire propriétaire de l’identifiant doit provenir du même locataire dans le domaine de l’URL, sinon la demande sera rejetée.

Si votre application ou API appelle l’un des points de terminaison répertoriés, vous devez configurer vos appels API pour vous assurer que l’identifiant du locataire demandeur et le nom d’hôte sont identiques :

• /oauth/token

• /co/authenticate

• /userinfo

• /login

• /oauth/revoke

• /mfa/challenge

• /p/<connection-type>/<ticket> (point de terminaison de fourniture de connexion d’entreprise)

Pour en savoir plus, consultez Migration de la validation de nom d’hôte de locataire.

Fin de vie : 30 avril 2022

Le 30 avril 2022, la version 12 de Node.js est sortie de la période de support à long terme (LTS), ce qui signifie que l’équipe de développement de Node.js ne rétroporte plus les correctifs de sécurité critiques vers cette version. Cela pourrait potentiellement exposer votre code d’extensibilité à des vulnérabilités de sécurité. Par conséquent, Auth0 migre de Node 12 vers Node 16.

Bien que la mise à jour de Node 16 n’introduira aucun changement radical dans la bibliothèque standard Node.js (les règles et les scripts d’action de base de données personnalisées sont affectés; veuillez consulter la section Modifications importantes - Règles et scripts d’action de base de données personnalisés uniquement); nous encourageons les clients utilisant la version 12 de Node.js à rester à jour avec les versions de support à long terme (LTS) actives de Node.js pour des raisons de sécurité et de conformité. Les clients qui utilisent encore la version 8 de Node ne sont plus conformes aux normes de sécurité et doivent migrer vers la version 16 de Node pour éliminer les risques de sécurité. Le 22 février 2022, nous avons supprimé l’environnement d’exécution de la version 8 de Node pour les locataires du nuage public et l’avons supprimé dans la version du nuage privé d’avril 2022. Après ces dates, les locataires encore configurés sur la version 8 de Node seront exposés à un risque d’interruption de service.

Déconseillé : 7 octobre 2021 (nuage public), 21 décembre 2023 (nuage privé)

‌‌Fin de vie :‌‌ 12 avril 2022 (nuage public), 30 juin 2022 (nuage privé)

À compter du 12 avril 2022 dans le nuage public et de décembre 2021 dans le nuage privé, les codes de jeton d’accès et d’autorisation seront émis avec des longueurs variables pour prendre en charge la spécification OAuth RFC6749 afin d’éviter que les clients ne fassent des hypothèses sur les valeurs du code d’autorisation et du jeton d’accès. Actuellement, les tailles des jetons d’accès et des codes d’autorisation sont fixes. La taille actuelle du code d’autorisation est plus courte que ce que certains professionnels de la sécurité recommandent. Grâce à ce changement, Auth0 fournit un code et un jeton plus forts tout en améliorant les performances des systèmes Auth0.

Les clients dont les systèmes étaient configurés pour utiliser une longueur précise de codes d’autorisation et de jetons d’accès ont dû passer d’une taille fixe à une taille variable avant le 12 avril 2022 (nuage public) ou le 30 juin 2022 (nuage privé).

Déconseillé : 15 avril 2020

Fin de vie : 25 février 2022 (nuage public), avril 2022 (version nuage privé)

À compter du 13 décembre 2019, Node.js v8 ne bénéficiait plus d’une assistance à long terme (LTS). Cela signifie que les correctifs de sécurité critiques n’étaient plus rétroportés vers cette version. Les clients qui sont toujours sur Node 8 ne sont pas conformes à la sécurité et doivent migrer vers Node 12 pour éliminer les risques de sécurité. Pour en savoir plus sur la façon de migrer votre version de Node au niveau du client de 8 à 12, consultez Migrer de Node.js 8 vers Node.js 12.

Étant donné que Node.js v12 a été retiré de LTS en 2022, nous encourageons fortement tous les clients utilisant les règles et les appels de migrer vers les actions avec Node 16 dès que possible, car la prise en charge de Node 12 de la part de la communauté Node.js a expirée officiellement le 30 avril 2022. Pour en savoir plus sur les étapes de migration, consultez Migrer les règles et appels vers les actions.

Déconseillé : 5 mai 2021 (nuage public)

Fin de vie : 3 novembre 2021 (nuage public)

La périphérie de réseau héritée Auth0 cessera de fonctionner sur le nuage public. Après le 3 novembre 2021, les locataires de nuage public qui n’ont pas effectué de migration vers la nouvelle périphérie de réseau Auth0 ne recevront plus de trafic. Tous les nouveaux domaines personnalisés sont automatiquement créés sur la nouvelle périphérie de réseau.

Déconseillé : 21 juillet 2020 (nuage public)

Fin de vie : 26 janvier 2021 (nuage public), février 2022 (version nuage privé)

Après le 26 janvier 2021, les requêtes adressées aux points de terminaison de Management API v2 renverront un maximum de 50 éléments pour les locataires du nuage public. Pour récupérer plus d’éléments, vous devez inclure les paramètres page et per_page. À partir du 21 juillet 2020, Auth0 affichera les journaux des locataires et une bascule de migration pour vous aider à vous préparer à ce changement.

• GET /api/v2/clients

• GET /api/v2/client-grants

• GET /api/v2/grants

• GET /api/v2/connections

• GET /api/v2/device-crecentials (lorsque le paramètre de requête type est utilisé)

• GET /api/v2/resource-servers

• GET /api/v2/rules

Tous les locataires de nuage public sont concernés s’ils sont créés avant le 21 juillet 2020 et appellent activement les points de terminaison concernés sans passer le paramètre per_page pour les requêtes qui peuvent renvoyer plus d’un résultat. Les locataires ne sont pas concernés s’ils sont créés après le 21 juillet 2020, n’utilisent pas les points de terminaison concernés, utilisent les points de terminaison concernés et transmettent le paramètre per_page ou effectuent des requêtes qui ne renvoient toujours qu’un seul résultat. Pour en savoir plus, consultez Migrer vers les requêtes paginées des points de terminaison de Management API v2.

Déconseillé : 17 juin 2021

Fin de vie : 20 décembre 2021

Pour assurer la cohérence de tous les déploiements Auth0 et nous concentrer sur l’amélioration de la fonctionnalité de domaine personnalisé Auth0, nous supprimons la fonctionnalité de domaine personnalisé du nuage privé le 20 décembre 2021. La cohérence nous permet ainsi d’améliorer la fonctionnalité et de résoudre les problèmes de fiabilité plus rapidement, d’améliorer l’efficacité opérationnelle et d’aider les clients à tirer plus rapidement parti des domaines personnalisés. Pour en savoir plus sur la migration vers les domaines personnalisés Auth0, consultez Migrer les domaines personnalisés du nuage privé.

Déconseillé : 25 mai 2021

Fin de vie : 1er décembre 2021

Le 1er décembre 2021, le comportement de déconnexion changera pour toujours rediriger les utilisateurs vers l’URI passé aux API de déconnexion Auth0 au lieu d’utiliser le paramètre de requête returnTo passé par les fournisseurs d’identité à /login/callback pendant l’exécution de la déconnexion. Si Auth0 ne dispose pas d’un enregistrement d’un appel précédent à l’une de ces API, la déconnexion se terminera, mais la redirection ne se produira pas et les utilisateurs finaux verront une page d’erreur. Pour en savoir plus, consultez le Guide de migration des redirections de déconnexion.

Déconseillé : 1er février 2021

Fin de vie : 30 septembre 2021 (nuage public), septembre 2021 (version mensuelle nuage privé)

Auth0 modifie le contrôle d'accès basé sur les rôles (RBAC) vers le Dashboard. Le rôle d’administrateur d’application défini aujourd’hui sera bientôt rendu obsolète. Après le 1er février 2021, les administrateurs ne pourront plus inviter de membres au rôle d’administrateur d’application obsolète. Les administrateurs existants spécifiques à l’application continueront à pouvoir utiliser le Dashboard avec les autorisations existantes définies jusqu’à la date de fin de vie.

Un nouvel ensemble de rôles du Dashboard est disponible pour une collaboration améliorée et plus sécurisée entre les membres de l’équipe, y compris les rôles d’observateur Éditeur – applications spécifiques remplace l’ancien rôle d’administrateur d’application pour les plans d’abonnement pour lesquels les rôles d’éditeur sont pris en charge.

Vos locataires étaient concernés par ce retrait si les critères suivants étaient remplis :

• Création antérieure au 1er février 2021.

• Au moins un membre du locataire avec le rôle d’administrateur d’application.

• Aucune activation de l’aperçu de la fonctionnalité des rôles Dashboard.

Depuis le 1er février 2021, Auth0 affiche un bouton de migration pour vous aider à vous préparer à ce changement. Pour en savoir plus, consultez Migrer vers la gestion des nouveaux rôles du Dashboard.

Déconseillé : 19 Janvier 2021

Fin de vie : 10 mai 2021 (nuage public), version nuage privé de juin (v 2106)

À compter du 10 mai 2021 pour le nuage public et pour la version de juin du nuage privé (v2106), la périphérie du réseau Auth0 n’acceptera plus le trafic TLS 1.0 ou TLS 1.1. Ces protocoles hérités sont peu sûrs, et présentent des faiblesses et des vulnérabilités bien connues au sein de l’industrie. Pour une sécurité maximale, tous les clients Auth0 doivent passer à TLS 1.2 ou à une version ultérieure. Les détails exacts et les étapes requises varieront en fonction de votre application. Pour en savoir plus, consultez Mettre à niveau vers TLS 1.2, quelles mesures prendre ? publié dans la communauté Auth0.

Déconseillé : janvier 2018

Fin de vie : janvier 2021

Auth0 a déconseillé l’utilisation de la bibliothèque auth0-analytics.js qui ajoute l’intégration de Facebook et Google Analytics avec Lock. Elle écoute les événements dans Lock et les transmet à la bibliothèque Auth0-tag-manager.js. Elle peut cependant encore fonctionner dans certains cas hérités. Cette bibliothèque n’est plus tenue à jour. Vous devrez peut-être écrire un code personnalisé pour utiliser auth0-tag-manage.js afin de gérer les demandes de proxy vers des bibliothèques d’analyse tierces telles que Facebook, X et Google.

Déconseillé : 31 août 2020

Fin de vie : 17 décembre 2020

Auth0 exige maintenant que vous fournissiez le paramètre user_id lorsque vous utilisez le point de terminaison GET /api/v2/device-credentials. Si votre demande ne fournit pas de paramètre user_id, un code d’état 400 sera renvoyé. Vérifiez le code depnote dans vos journaux de locataire pour voir si vous êtes concerné par cette obsolescence. Pour en savoir plus, consultez Vérifier les erreurs d’obsolescence.

Auth0 a déterminé les locataires concernés par cette obsolescence et a communiqué avec les administrateurs de ces locataires. Si votre locataire effectue actuellement des demandes sans user_id, vous devez effectuer la modification dès que possible.

‌‌Déconseillé :

• Nuage public : 18 novembre 2020

• Nuage privé : 1er décembre 2020

Fin de vie :

• Nuage public : 18 mai 2021

• Nuage privé : version Nuage privé juin (v 2106)

Auth0 définissait précédemment le champ email_verified sur true dans les connexions Azure AD et ADFS. Si vous utilisiez des connexions Azure AD et ADFS avec cette date d’obsolescence, vous disposez d’un paramètre de locataire qui remplace le paramètre de connexion pour la vérification de l’adresse courriel et qui conserve le comportement précédent.

Le 18 mai 2021, dans le nuage public et dans la version de juin du nuage privé (v2106), Auth0 commencera à utiliser la propriété de connexion pour toutes les connexions Azure AD et ADFS. Vous devez vous assurer que toutes vos connexions sont correctement configurées avant cette date. Pour en savoir plus, consultez Vérification des courriels pour Azure AD et ADFS.

En vigueur : février 2020

Google Chrome v80 change la façon dont les témoins sont gérés. À cette fin, Auth0 mettra en œuvre les changements suivants dans la façon dont les témoins sont gérés :

• La valeur des témoins dont l’attribut samesite n’a pas été défini sera lax.

• Les témoins ayant un attribut sameSite=none ont été sécurisés, afin d’être enregistrés dans le groupe de témoins du navigateur.

L’objectif de ces changements est d’améliorer la sécurité et d’aider à atténuer les attaques CSRF. Pour plus de détails, consultez Changements de l’attribut des témoins sameSite.

Déconseillé : 10 novembre 2018

Fin de vie : 30 juin 2019 (nuage public), mai 2021 (version mensuelle nuage privé)

User Search v2 est déconseillé pour le nuage public depuis le 30 juin 2019. Des notifications ont été envoyées aux clients qui doivent effectuer cette migration.

User Search v1 et les points de terminaison v2 ne sont plus proposés pour le nuage privé et ont été remplacés par le nouveau point de terminaison User Search v3.

Auth0 a déconseillé l’utilisation du point de terminaison /passwordless/start à partir d’applications confidentielles lorsque Auth0 ne peut pas authentifier que l’appel est effectué au nom de l’application. Pour en savoir plus, consultez Migrer vers un point de terminaison sans mot de passe à partir d’applications confidentielles. Protection contre le détournement de clics pour les changements de connexion universelle

Auth0 a ajouté la possibilité d’ajouter des en-têtes (que nous recommandons fortement), pour empêcher le détournement de clics lorsque vous insérez votre page de connexion dans un iframe. Pour plus de détails, reportez-vous à la section Protection contre le détournement de clics pour les changements de connexion universelle.

Déconseillé : 31 mars 2018

Fin de vie : à définir

Auth0 déconseille l’utilisation de jetons d’ID comme identifiants pour appeler certains des utilisateurs et des points de terminaison de l’appareil et les remplace par l’utilisation de jetons d’accès à la place. Pour plus de détails, consultez Migrer vers les points de terminaison du Management API avec des jetons d’accès et Migrer vers Associer des comptes d’utilisateurs liés avec des jetons d’accès.

Déconseillé : 8 juillet 2017

Fin de vie : à définir

À compter du 8 juillet 2017, Auth0 a déconseillé le point de terminaison /oauth/ro pour les connexions par mot de passe et sans mot de passe. Vous pouvez désormais mettre en œuvre la même fonctionnalité à l’aide du point de terminaison /oauth/token. Pour en savoir plus, consultez Migration du flux de mot de passe du propriétaire de ressource.

Déconseillé : octobre 2016

Fin de vie :

• Nuage public : 13 juillet 2020

• Nuage privé : version mensuelle de novembre 2020

Management API v1 atteindra sa fin de vie dans le nuage public le 13 juillet 2020. Management API v1 sera incluse dans le nuage privé jusqu’à la version mensuelle de novembre 2020, qui est la première version qui n’inclura pas Management API v1. Vous devrez peut-être prendre des mesures avant cette date pour éviter toute interruption de votre service. Des notifications ont été et continueront d’être envoyées aux clients qui doivent effectuer cette migration.

Déconseillé : 05 mars 2020

Fin de vie : 31 mars 2020

Facebook a annoncé qu’à partir du 31 mars 2020, il déconseillait les API Instagram héritées et qu’aucune autre connexion avec Instagram ne serait proposée. Pour plus de détails, reportez-vous à la section Obsolescence des connexions Instagram.

Déconseillé : 1er mars 2020

Fin de vie : 1er mars 2020

Yahoo a modifié la façon de récupérer le profil utilisateur et les informations qu’il contient. Pour plus de détails, reportez-vous à la section Changements apportés à l’API Yahoo.

Déconseillé : 11 avril 2019

Fin de vie : 11 avril 2019

Depuis le 11 avril 2019, Google a déconseillé et remplacé Google Cloud Messaging (GCM) par Firebase Cloud Messaging (FCM). Pour plus de détails, reportez-vous à la section Migration de Google vers Firebase Cloud Messaging.

Déconseillé : 30 avril 2019

Fin de vie : 30 juillet 2019

Le 30 avril 2019, Facebook a déconseillé l’utilisation du champ Social Context (Contexte social) pour les nouvelles applications. Pour plus de détails, reportez-vous à la section Obsolescence du champ de contexte social‌ de Facebook.

Déconseillé : 1er août 2018

Fin de vie : Graph API v3, version du 8 janvier 2019

Depuis le 1er août 2018, Facebook a modifié les autorisations et les champs de l’API Graph Facebook qui peuvent être demandés. Auth0 a mis à jour Facebook Connections (Connexions Facebook) pour refléter ces changements et a modifié l’interface de connexion pour plus de clarté. Consultez Journal des modifications récentes de connexion Facebook : Modifications récentes de la connexion Facebook pour plus de détails et les dates clés. Pour plus de détails, reportez-vous à la section Modifications de l’API Graph de Facebook.

Nous améliorons continuellement la sécurité de notre service. Dans le cadre de cet effort, nous avons déconseillé l’API Lock héritée, qui se compose des points de terminaison /usernamepassword/login et /ssodata. Ces points de terminaison sont utilisés par Lock.js v8, v9 et v10 et Auth0.js, v6, v7 et v8, et peuvent également être appelés directement à partir d’applications.

Depuis le 6 août 2018, Auth0 a désactivé définitivement l’API Lock héritée. Cette suppression de service atténue entièrement la vulnérabilité CSRF divulguée en avril 2018. Cela met également fin à la période de grâce de suppression douce qui a été annoncée pour la première fois le 16 juillet 2018, ce qui signifie que l’API Legacy Lock ne peut plus être réactivée.

Si votre migration de l’API Lock héritée n’est pas encore terminée, vos utilisateurs peuvent subir une panne, des échecs de connexion ou d’autres effets indésirables. Vous devrez terminer votre migration afin de restaurer les fonctionnalités normales. Vérifiez les erreurs d’obsolescence pour déterminer dans les journaux de vos locataires la ou les sources de toute erreur liée aux obsolescences.

Si vous mettez actuellement en œuvre la connexion dans votre application avec Lock v8, v9 ou v10, ou Auth0.js v6, v7 ou v8, vous êtes concerné par ces modifications. De plus, vous êtes concerné si votre application appelle les points de terminaison /usernamepassword/login ou /ssodata directement via l’API.

Nous recommandons que les applications qui utilisent la connexion universelle mettent à jour les versions des bibliothèques qu’elles utilisent sur la page de la connexion.

Cependant, ceux qui utilisent Lock ou Auth0.js intégré dans leurs applications, ou qui appellent directement les points de terminaison API concernés, sont tenus de se mettre à jour, et les applications qui utilisent encore des points de terminaison obsolètes cesseront de fonctionner correctement après la date de suppression du service.

Les bibliothèques et les trousses SDK non mentionnées explicitement ici ne sont pas affectées par cette migration.

Déconseillé : 21 mai 2019

Fin de vie :

• Version gratuite : 9 juillet 2019

• Version Essential (anciennement Developer) : 20 août 2019

• Version Professional (anciennement Developer Pro) : 20 août 2019

• Version Enterprise : 4 novembre 2019

Pour fournir à nos clients la solution la plus fiable et la plus évolutive, Auth0 a déconseillé le moteur de recherche Tenant Logs Search Engine v2 au profit de la v3. Auth0 migre de manière proactive les clients non concernés par ce changement, tandis que ceux qui sont potentiellement concernés sont avisés d’opter pour la v3 pendant la période de grâce prévue. Pour plus de détails, reportez-vous à la section Migration de Tenant Log Search v1 à V2.

Au 30 septembre 2017, Auth0 a mis à jour ses environnements cloud et le trafic en provenance d’Australie provient de nouvelles adresses IP. Si vous autorisez la liste des adresses IP, vous devrez ajouter les nouvelles adresses à vos règles de pare-feu.

Vous êtes touchés par cette modification si vous utilisez une connexion personnalisée par base de données, une règle et/ou un fournisseur de messagerie personnalisé qui se connecte à votre environnement, et que vous avez mis en œuvre des restrictions par pare-feu pour les plages d’adresses IP. Vous devrez vous assurer que les adresses IP suivantes sont autorisées à passer par votre pare-feu :

13.55.232.24, 13.54.254.182, 13.210.52.131, 52.62.91.160, 52.63.36.78, 52.64.84.177, 52.64.111.197, 52.64.120.184, 54.66.205.24, 54.79.46.4, 54.153.131.0

Au 30 septembre 2017, Auth0 a mis à jour ses environnements cloud et le trafic en provenance d’Europe provient de nouvelles adresses IP. Si vous autorisez la liste des adresses IP, vous devrez ajouter les nouvelles adresses à vos règles de pare-feu.

Vous êtes touchés par cette modification si vous utilisez une connexion personnalisée par base de données, une règle et/ou un fournisseur de messagerie personnalisé qui se connecte à votre environnement, et que vous avez mis en œuvre des restrictions par pare-feu pour les plages d’adresses IP. Vous devrez vous assurer que les adresses IP suivantes sont autorisées à passer par votre pare-feu :

34.253.4.94, 35.156.51.163, 35.157.221.52, 52.16.193.66, 52.16.224.164, 52.28.45.240, 52.28.56.226, 52.28.184.187, 52.28.212.16, 52.29.176.99, 52.50.106.250, 52.57.230.214, 52.211.56.181, 52.213.216.142, 52.213.38.246, 52.213.74.69

Au 12 juillet 2017, Auth0 a amélioré la mise à l’échelle et la disponibilité de Auth0 CDN. Nous utilisons maintenant Amazon CloudFront. Nous avons déjà effectué ce changement dans l’environnement américain, et nous sommes maintenant prêts à le faire en Europe et en Australie.

Vous êtes concerné si vous utilisez Lock (hébergé par notre CDN) en Europe ou en Australie. Ce changement ne devrait pas perturber ou modifier le comportement de vos applications, vous n’avez donc rien à faire. Cette notification est fournie à titre d’information uniquement.

Le 31 mai 2017, dans le cadre des initiatives d’Auth0 en matière d’amélioration de la qualité, nous avons ajouté la possibilité d’exécuter des règles pendant l’échange d’octroi de mot de passe de propriétaire de ressource OAuth 2.0 (l’échange de mot de passe) et l’échange de jeton d’actualisation.

Vous utilisez cette caractéristique si vous appelez le point de terminaison /oauth/token de notre Authentication API avec grant_type = "password" , grant_type = "http://auth0.com/oauth/grant-type/password-realm", ou grant_type = "refresh_token".

Vous pourriez être concerné si vous utilisez actuellement ces échanges et que des règles sont définies dans le Dashboard. Afin d’assurer une transition en douceur, nous avons désactivé l’exécution des règles sur ces échanges spécifiques pour votre locataire. Ces règles s’appliqueront désormais à tous les nouveaux clients, ainsi qu’aux clients qui n’ont pas encore utilisé ces échanges.

Vous pouvez ajouter une logique à vos règles pour qu’elle modifient leur comportement vis à vis de ces échanges, en consultant la propriété context.protocol :‌‌

• ‌‌oauth2-password indique un échange de mot de passe (et password-realm)

• ‌‌oauth2-refresh-token indique un échange de jetons d’actualisation

Si vous souhaitez activer le nouveau comportement sur ce locataire pour tester la date d’activation obligatoire, connectez-vous à Dashboard et activez la bascule Run Rules on Password and Refresh Token Exchanges (Exécuter des règles sur les échanges de mots de passe et de jetons d’actualisation) dans Tenant Settings (Paramètres du locataire) > Advanced (Avancés).

Le 1er mars 2017, dans le cadre de l’initiative d’Auth0 d’améliorer la sécurité et la conformité aux normes, nous avons arrêté de prendre e charge la liaison des comptes dans le cadre du rappel d’autorisation (c’est-à-dire d’accepter un jeton d’accès dans un appel authorize).

Si vous avez reçu une notification par courriel à ce sujet, vous êtes concerné par ce changement. Lorsque vous travaillez à la mise à jour de vos applications pour utiliser Management API pour lier des comptes, vous pouvez vérifier si vous êtes toujours concerné en vérifiant les avertissements dans les journaux de vos locataires. Ces entrées seront consignées si vous envoyez un jeton d’accès dans vos appels d’autorisation.

À compter du 20 février 2017, Auth0 s’est étendu à de nouvelles régions des États-Unis et le trafic en provenance de ces régions aura de nouvelles adresses IP. Si vous autorisez la liste des adresses IP, vous devrez ajouter les nouvelles adresses à vos règles de pare-feu.

Vous êtes touchés par cette modification si vous utilisez une connexion personnalisée par base de données, une règle et/ou un fournisseur de messagerie personnalisé qui se connecte à votre environnement, et que vous avez mis en œuvre des restrictions par pare-feu pour les plages d’adresses IP. Vous devrez ajouter les adresses IP suivantes aux règles de votre pare-feu :

138.91.154.99, 54.183.64.135, 54.67.77.38, 54.67.15.170,54.183.204.205, 54.173.21.107, 54.85.173.28, 35.167.74.121, 35.160.3.103,35.166.202.113, 52.14.40.253,52.14.38.78, 52.14.17.114, 52.71.209.77, 34.195.142.251, 52.200.94.42

Avant le 1er février 2017, le flux de réinitialisation du mot de passe d’Auth0 permettait à un utilisateur de saisir son adresse courriel et un nouveau mot de passe. Cela déclenchait l’envoi d’un courriel à l’utilisateur pour lui demander de confirmer s’il avait bien demandé une réinitialisation du mot de passe.

Le problème était que, par inadvertance, un utilisateur pouvait cliquer sur le lien de confirmation, ce qui permettait à quelqu’un d’autre de modifier son mot de passe.

Lock version 9 et les versions supérieures utilisent exclusivement le nouveau flux de réinitialisation de mot de passe. Lock 8 et les versions inférieures ne gèrent pas le nouveau flux de réinitialisation du mot de passe. Nous vous recommandons vivement de passer à Lock 9 ou à une version supérieure dès que possible.

À compter du 6 décembre 2016, lorsqu’une redirection est effectuée à partir d’une règle Auth0, Auth0 génère et envoie un paramètre d’état en HTTP et vérifie la présence d’un paramètre d’état valide lorsque le flux revient au point de terminaison/continue. Le site vers lequel va la redirection doit capturer la valeur du paramètre d’état et la renvoyer en l’ajoutant en tant que paramètre lors du retour au point de terminaison /continue.

Vous êtes touché par cette modification uniquement si vous utilisez la redirection à partir de règles, et que vous ne capturez et ne renvoyez pas encore (vers le point de terminaison /continue) le paramètre d’état.

Avant le 13 septembre 2016, le point de terminaison précédent pour la suppression de tous les utilisateurs était DELETE /api/v2/users. Ceci est similaire au point de terminaison pour supprimer un utilisateur : DELETE /api/v2/users. Pour éviter les demandes accidentelles de suppression de tous les utilisateurs au point de terminaison, l’URL a été modifiée par DELETE /api/v2/allusers. Cela devrait garantir que seuls les appels intentionnels à ce point de terminaison puissent aboutir.

Vous n’êtes concerné par la modification que si vous utilisez actuellement le point de terminaison de suppression de tous les utilisateurs. Si c’est le cas, le seul changement que vous devez faire est de modifier l’URL comme expliqué ci-dessus.

Depuis le 29 août 2016, le fournisseur de messagerie intégré d’Auth0 n’est plus pris en charge pour une utilisation dans un environnement de production. Les courriels envoyés à l’aide du fournisseur Auth0 ne seront plus personnalisables. Ils seront limités au modèle et vous ne pourrez pas modifier l’adresse de départ ou la ligne d’objet.

Le service de messagerie intégré peut continuer à être utilisé à des fins de test, mais vous devrez passer à un service tiers pris en charge par Auth0 (Amazon SES, Mandrill, SendGrid) ou un autre fournisseur de type SMTP avant de faire passer vos applications en production. Si vous utilisez déjà un fournisseur de messagerie personnalisé, aucune action n’est requise.

Depuis le 8 août 2016, le format de l’objet JSON du profil utilisateur (jeton d’ID) qui est renvoyé par les Authentication API Auth0 a été modifié pour supprimer le jeton d’accès du fournisseur d’identité et est inclus dans le tableau identities du profil utilisateur.

Pour obtenir le jeton d’accès du fournisseur d’identité d’un utilisateur, vous devrez faire un appel HTTP GET au point de terminaison /api/v2/users/{user-id} contenant un jeton d’API généré avec la permission read:user_idp_tokens. Vous aurez toujours accès au jeton d’accès du fournisseur d’identité dans l’argument user dans les règles d'Auth0.

Vous êtes concerné par cette modification uniquement si vous utilisez le jeton d’accès du fournisseur d’identité (identities[0].access_token dans le profil utilisateur) en dehors de règles pour appeler d’autres services à partir du fournisseur d’identité (comme l’API Graph de Facebook, les API de Google, etc.). Si votre locataire a été créé après le changement, la mise à jour sera effectuée automatiquement.

À compter du 1er juin 2016, lors de l’appel du point de terminaison Tokeninfo, l’URL de l’appel d’API (par exemple https ://${ account.namespace}/) doit correspondre à la valeur de l’attribut iss du jeton d’ID en cours de validation. Si ces valeurs ne correspondent pas, la réponse sera HTTP 400 - Bad Request.

Si vous appelez directement le point de terminaison Tokeninfo, assurez-vous que la valeur de l’attribut iss du jeton d’ID en cours de validation correspond à votre espace de noms de locataire Auth0 : https://{yourDomain}/. Vous pouvez utiliser jwt.io pour décoder le jeton afin de confirmer la valeur de l’attribut iss.

Le 27 avril 2016, le fournisseur de messagerie intégré d’Auth0 a commencé à envoyer tous les courriels à partir d’une adresse de départ prédéfinie (no-reply@auth0user.net). Les fournisseurs de messagerie personnalisés sont maintenant gratuits. Pour personnaliser l’adresse « de », vous pouvez passer à un service tiers pris en charge par Auth0 (Amazon SES, Mandrill, SendGrid) ou à un autre fournisseur basé sur SMTP. Si vous utilisez déjà un fournisseur de messagerie personnalisé, rien ne changera.

La configuration jwt_configuration.secret_encoded n’est plus acceptée par les points de terminaison PATCH et POST des applications.

Afin de mieux se conformer à la spécification OIDC, Auth0 ne génère plus et n’accepte plus de secrets d’application encodés en base64 pour les nouvelles applications.

Les applications existantes à secrets codés demeurent intactes et les secrets codés ne sont en rien modifiés, mais les nouvelles applications n’utilisent plus le codage base64. Ainsi, l’indicateur secret_encoded ne sera plus accepté ou nécessaire.

Vous êtes concerné par cette modification uniquement si vous interagissez directement avec ces points de terminaison.