Propriétés protégées dans les connexions sociales non personnalisées
Obsolète : 30 juillet 2024Fin de vie : 31 janvier 2025Les points de terminaison de la Management API pour les connexions (GET, POST et PATCH) ne permettront plus de récupérer ou de définir les valeurs des propriétés protégées suivantes dans l’objet options des connexions sociales non personnalisées :
authorizationURL
tokenURL
userInfoUrl
baseUrl
userAuthorizationURL
grant_type
authorizationURL
tokenURL
userInfoUrl
baseUrl
userAuthorizationURL
grant_type
Les connexions sociales non personnalisées désignent toute connexion sociale dont la logique d’implémentation est entièrement contrôlée par le service Auth0 lui-même. Cette catégorie exclut les connexions créées explicitement comme connecteurs sociaux personnalisés ainsi que celles offertes sous forme d’intégrations Marketplace qui reposent sur la fonctionnalité de connexion sociale personnalisée.
Suppression injustifiée de sessions après des mises à jour d’utilisateurs via la Management API
Obsolète : 11 février 2025Fin de vie : 19 août 2025Le point de terminaison Mettre à jour un utilisateur de la (PATCH /api/v2/users/{id}) n’invalidera plus les sessions des utilisateurs d’une connexion de base de données lorsque :
les attributs email ou email_verified sont définis sur une valeur inchangée.
l’attribut email_verified est défini sur la valeur true.
Utilisation obligatoire du SNI pour les requêtes HTTPS
Obsolète : 29 octobre 2024Fin de vie : 29 avril 2025Le service Auth0 exigera l’utilisation de Server Name Indication (SNI) pour toutes les requêtes HTTPS. Le SNI est une extension du protocole TLS qui permet au client d’indiquer le nom d’hôte auquel il souhaite se connecter dès le début du processus de négociation.Depuis leur création, la grande majorité de nos environnements Private Cloud et certains de nos environnements Public Cloud appliquent déjà cette exigence. Par exemple, les environnements Public Cloud CA-1, JP-1 et UK-1 ont toujours exigé le SNI.Avec ce changement, l’exigence relative au SNI s’appliquera aux autres environnements. Pour en savoir plus sur les échéanciers propres à chaque environnement, consultez l’article End-of-Life Rollout for Mandatory Use of SNI for HTTPS Requests.
Utilisez toujours HTTPS pour communiquer avec Auth0
Obsolète : 4 septembre 2024Fin de vie : 4 octobre 2024À compter du 4 octobre 2024, Auth0 ne redirigera plus automatiquement les requêtes API effectuées en HTTP non chiffré vers le protocole HTTPS sécurisé et renverra une erreur. Pour éviter toute interruption de service, mettez à jour toutes les URL HTTP que vous utilisez ou publiez pour qu’elles utilisent plutôt HTTPS.
Transition de la Management API : l’attribution des rôles nécessitera désormais le scope de création
Obsolète : 7 mars 2024Fin de vie : 10 septembre 2024Les scopes de la Management API pour le point de terminaison User-Roles (POST /api/v2/users/{id}/roles) exigeront le scope create:role_members. Cela reflète mieux les autorisations prévues pour ce scope.Auparavant, il était possible d’attribuer des rôles à des utilisateurs avec le scope read:roles.
Mettre à jour les applications qui utilisent l’authentification cross-origin
Obsolète : 25 avril 2024Fin de vie : 10 octobre 2024Les nouvelles applications créées dans Auth0 auront l’authentification cross-origin désactivée par défaut. Les appels à certains endpoints du Management API (Get Clients, Get Client by ID) devront être modifiés pour utiliser cross_origin_authentication.
Retirer l’accès aux Subscription Tickets pour les administrateurs de locataire
Obsolète : 5 juin 2024Fin de vie : 5 août 2024L’accès aux Subscription Tickets dans le Centre de soutien Auth0 changera le 5 août 2024. Pour conserver l’accès permettant de voir et de gérer tous les billets d’assistance créés par tous les utilisateurs d’un locataire, le nouveau rôle Elevated Support Access est requis.
Obsolescence des liens de réinitialisation du mot de passe et de vérification du courriel dans les journaux du locataire
Obsolète : 7 décembre 2023Fin de vie : 5 février 2024Les liens de réinitialisation du mot de passe et de vérification du courriel ne seront plus consignés dans les journaux du locataire. Ces liens peuvent être récupérés dans la réponse à une requête de réinitialisation du mot de passe ou de vérification du courriel adressée à la .
Réduction de la durée de validité maximale des transactions de connexion
Obsolète : 5 septembre 2023 (Public Cloud), 21 novembre 2023 (Private Cloud)Fin de vie : 21 février 2024Avec ce changement, nous imposerons une durée de validité maximale d’une heure pour les flux de connexion avec redirection. Les flux de connexion qui prennent plus d’une heure à se terminer expireront dans Universal Login et Classic Login. Après l’expiration, toute action ultérieure effectuée depuis le navigateur de l’utilisateur final (p. ex. saisie du courriel/mot de passe, redirection vers Actions/Rules, etc.) entraînera soit :
une redirection vers la route de connexion par défaut de l’application associée afin de relancer le flux comme nouvelle transaction de connexion;
une page d’erreur si la route de connexion par défaut n’est pas configurée.
Obsolescence des scopes non enregistrés dans les jetons d’actualisation
Obsolète : 12 juillet 2023Fin de vie : 17 janvier 2024Nous améliorons l’évaluation des scopes lors de l’échange de afin de garantir qu’il n’est pas possible de demander des scopes non enregistrés. Les valeurs de scope personnalisées qui ne sont pas enregistrées pour la valeur aud ou audience (pour une API enregistrée dans votre locataire) sont considérées comme des scopes non enregistrés.Avec ce changement, l’évaluation des scopes de l’API inclura tous les scopes personnalisés demandés pendant l’authentification de l’utilisateur ou injectés par l’extensibilité, comme les Rules. Cette évaluation vérifiera que tous les scopes sont enregistrés et renverra une erreur si ce n’est pas le cas.
Obsolescence des dépôts auth0-cordova, angular-auth0 et express-oauth2-bearer
Obsolète : 27 avril 2023Fin de vie : 30 juin 2023 (express-oauth2-bearer), 27 octobre 2023 (angular-auth0 et auth0-cordova)Nous avons déclaré obsolètes les dépôts suivants :
Ces bibliothèques ne seront plus prises en charge. Veuillez les supprimer de tout projet actif avant ces dates.Si vous avez des questions ou des préoccupations, veuillez nous contacter sur GitHub.
Migration des Actions de Node.js 16 vers Node.js 18
Date cible de migration : 11 sept. 2023Dans le cadre de notre engagement à prendre en charge chaque nouvelle version LTS de Node.js dans Actions et à rester alignés sur la communauté des développeurs Node.js, nous lançons Node 18 alors que Node 16 est toujours en LTS active. Nous encourageons vivement tous nos clients à passer dès aujourd’hui à Node 18 afin de tirer pleinement parti de sa période LTS. N’oubliez pas que, même si la version LTS de Node 16 demeure offerte jusqu’en septembre, son utilisation peut comporter certains risques après la fin du LTS, et nous vous recommandons de passer à Node 18.Node.js 18 est maintenant disponible en disponibilité générale (GA) dans l’ensemble de nos fonctionnalités d’extensibilité. Cela comprend Actions, Rules, Hooks, les scripts de base de données et les connexions sociales personnalisées. Nous encourageons fortement tous les clients à passer à Node 18 d’ici le 11 sept. 2023 afin de respecter les meilleures pratiques de sécurité du code.
Prise en charge d’edge.js dans les fonctionnalités d’extensibilité
Obsolète : 21 décembre 2022Fin de vie : 21 juin 2023Aprè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 auparavant en charge un sous-ensemble du langage C# pour écrire du code d’extensibilité pour Rules, Hooks et les scripts de base de données personnalisés, au moyen d’un module Node.js appelé edge.js.L’abandon de la prise en charge de l’exécution de .NET et de C# à partir de Node.js dans les fonctionnalités d’extensibilité est essentiel pour maintenir une plateforme performante et sécurisée capable d’exécuter du code non fiable. Ce changement nous permettra de continuer à améliorer nos solutions d’extensibilité de nouvelle génération.
Pour en savoir plus, consultez Migrer depuis les fonctionnalités d’extensibilité edge.js.
Prise en charge d’oracledb dans les fonctionnalités d’extensibilité
Obsolète : 21 décembre 2022Fin de vie : 21 juin 2023Auth0 ne prendra plus en charge le module complémentaire auth0-claims-provider pour SharePoint 2010/2013 après le 31 juillet 2023.Après le 21 juin 2023, Auth0 ne prendra plus en charge les connexions aux bases de données Oracle depuis Node.js dans les fonctionnalités d’extensibilité. Auth0 prenait auparavant en charge les connexions aux bases de données Oracle à partir du code d’extensibilité pour Rules, Hooks et les scripts de base de données personnalisés au moyen d’un module Node.js appelé oracledb.L’abandon de la prise en charge des connexions aux bases de données Oracle depuis Node.js dans les fonctionnalités d’extensibilité est essentiel pour maintenir une plateforme performante et sécurisée permettant d’exécuter du code non approuvé. Ce changement nous permettra de continuer à améliorer nos solutions d’extensibilité de nouvelle génération.Pour en savoir plus, consultez Migrer depuis les fonctionnalités d’extensibilité oracledb.
Fournisseur de claims Auth0 pour SharePoint 2010 / 2013
Obsolète : 31 janvier 2023Fin de vie : 31 juillet 2023Auth0 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 plus utiliser le « SharePoint People Picker » avec les connexions Auth0 pour attribuer des autorisations aux utilisateurs de SharePoint 2010/2013.Vous devez supprimer toute intégration avec le module complémentaire auth0-claims-provider avant le 31 juillet 2023. Après cette date, toute intégration restante avec le module complémentaire auth0-claims-provider cessera de fonctionner correctement et pourrait avoir des répercussions sur les utilisateurs de vos applications.
Pagination par point de contrôle pour le point de terminaison Get Role Users
Obsolète : 9 novembre 2022Fin de vie : 9 mai 2023Pour améliorer les performances, le point de terminaison Get Role Users de la Management API ne renverra plus un total de plus de 1 000 résultats que si la méthode de pagination par point de contrôle est utilisée. Cette méthode de pagination est optimisée pour prendre en charge de grands volumes de résultats. La méthode de pagination par décalage sera limitée à 1 000 résultats.Pour en savoir plus sur l’implémentation des deux méthodes de pagination, consultez la documentation de la Management API pour le point de terminaison Get Role Users.
Obsolète : 28 juillet 2022 (Public Cloud), 31 août 2022 (Private Cloud)Fin de vie : 30 janvier 2023 (Public Cloud), 18 avril 2023 (Private Cloud)À compter du 30 janvier 2023 sur Public Cloud et du 18 avril 2023 sur Private Cloud, Auth0 autorisera l’ajout de claims personnalisées privées sans espace de noms aux jetons à l’aide d’Auth0 Actions et dans les réponses du point de terminaison /userinfo de l’Authentication API. Auparavant, Auth0 autorisait les claims avec espace de noms dans les jetons d’accès et les au moyen du code d’extensibilité (Rules / Hooks / Actions). La migration vers les claims personnalisées permet d’ajouter des claims personnalisées privées sans espace de noms ainsi que des claims de profil utilisateur OIDC aux ; les ID tokens prennent actuellement en charge les claims de profil utilisateur et prendront aussi en charge les claims personnalisées privées sans espace de noms. Ces claims seront également ajoutées à la réponse /userinfo d’Auth0. Pour commencer la migration, consultez le guide de migration des claims personnalisées.Si votre locataire exécute du code d’extensibilité (Rules / Hooks / Actions) qui tente de définir des claims personnalisées sans espace de noms qui, jusqu’à cette obsolescence, étaient ignorées, ces claims commenceront alors à apparaître dans les jetons et dans la réponse /userinfo. Nous vous recommandons de vérifier votre configuration et les journaux Auth0.Avec l’ajout de claims privées sans espace de noms, Auth0 applique les restrictions suivantes, qui pourraient affecter votre locataire :
Auth0 limitera la charge utile des claims personnalisées à un maximum de 100 KB.
Auth0 limitera la personnalisation ou la modification des claims standard ou des claims utilisées en interne par Auth0.
À l’avenir, Auth0 pourrait restreindre l’utilisation d’autres claims qui ne figurent pas dans la liste ci-dessus. Dans ces cas, les clients seront avisés dans un délai raisonnable pour effectuer la migration.
Auth0 limitera la création de claims personnalisées privées sans espace de noms dans les jetons d’accès dont l’ est Auth0, à l’exclusion du point de terminaison /userinfo.
Seules les claims de profil utilisateur OIDC spécifiées peuvent être ajoutées aux jetons d’accès.
Auth0 limitera la création d’une claim personnalisée commençant par le caractère $.
Obsolète : 13 juin 2022Fin de vie : 31 janvier 2023Nous apportons des améliorations à l’infrastructure sous-jacente qui prend en charge Auth0 Private Cloud en introduisant une pile technologique moderne fondée sur Kubernetes, ainsi que des mises à niveau des bases de données. Nous travaillons actuellement avec tous les clients d’Auth0 Private Cloud pour planifier la mise à niveau de leur déploiement de Private Cloud vers la nouvelle pile d’infrastructure au cours de l’année, et nous mettrons fin à l’ancienne pile d’ici le 31 janvier 2023.De plus, 2205 (version de mai 2022) est la dernière version officielle de l’ancienne plateforme Private Cloud. Tout bogue ou toute vulnérabilité de sécurité sera évalué et corrigé dans des versions correctives, au besoin. Avant la mise à niveau vers la nouvelle pile d’infrastructure, les environnements devront être mis à jour vers la version minimale compatible afin de permettre la mise à niveau.Veuillez communiquer avec votre gestionnaire de compte technique pour toute question.
Obsolète : 4 mai 2022 (Public Cloud), 9 juin 2022 (version 2205 de Private Cloud)Fin de vie : 2 mai 2023 (Public Cloud), 6 janvier 2023 (Private Cloud)À compter du 4 mai 2022 dans Public Cloud et du 9 juin 2022 dans Private Cloud, les extensions de journaux Auth0 suivantes deviendront obsolètes :
Webhooks de l’Authentication API Auth0
Webhooks de la Management API Auth0
Journaux vers Cloudwatch
Journaux vers Logentries
Journaux vers Loggly
Journaux vers Logstash
Journaux vers Papertrail
Journaux vers Splunk
Journaux vers Sumo Logic
Obsolète : 2 novembre 2022 (Public Cloud), 21 décembre 2022 (Private Cloud)Fin de vie : 2 mai 2023 (Public Cloud), 31 mai 2023 (Private Cloud)À compter du 2 novembre 2022 dans Public Cloud et du 21 décembre 2022 dans Private Cloud, les extensions de journaux Auth0 suivantes deviendront obsolètes :
Journaux vers Segment
Journaux vers Mixpanel
Journaux vers AppInsights
Journaux vers Azure Blob Storage
Toutes les extensions de journaux énumérées ci-dessus sont maintenant obsolètes. Vous pouvez configurer une fonctionnalité équivalente à l’aide de flux d’événements de journaux ou d’intégrations dans le Auth0 Marketplace. À compter du 2 novembre 2022 dans Public Cloud et du 21 décembre 2022 dans Private Cloud, Auth0 ne prendra plus en charge les extensions de journaux installées figurant dans la liste ci-dessus. Pour en savoir plus, consultez Migrer depuis les extensions de journaux.
Obsolète : 9 décembre 2021 et décembre 2021 (version 2112.2 de Private Cloud)Fin de vie : 9 juin 2022 et 9 septembre 2022 (Private Cloud)À compter du 9 juin 2022 dans Public Cloud et du 9 septembre 2022 dans Private Cloud, Auth0 renforcera la sécurité des appels d’API en ajoutant une étape de validation des noms d’hôte des locataires au processus d’identification de l’Authentication API. Lorsqu’un appel est effectué, l’Authentication API validera l’identifiant d’entité (p. ex. : client_id) du locataire à l’origine de la requête, ainsi que le nom du locataire dans le domaine de l’URL. Le locataire auquel appartient l’identifiant doit être le même que celui indiqué dans le domaine de l’URL, sinon la requête sera rejetée.Si votre application ou votre API appelle l’un des points de terminaison ci-dessous, vous devez configurer vos appels d’API pour vous assurer que l’identifiant du locataire à l’origine de la requête et le nom d’hôte correspondent :
/oauth/token
/co/authenticate
/userinfo
/login
/oauth/revoke
/mfa/challenge
/p/<connection-type>/<ticket> (point de terminaison de provisionnement des connexions d’entreprise)
Fin de vie : 30 avril 2022Le 30 avr. 2022, Node.js v12 a cessé d’être pris en charge à 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 exposer votre code d’extensibilité à des vulnérabilités de sécurité. Par conséquent, Auth0 procède à la migration de Node 12 vers Node 16.Bien que la mise à jour vers Node 16 n’introduise aucun changement incompatible dans la bibliothèque standard de Node.js (les Rules et les Custom Database Action Scripts sont concernés; consultez la section Changements incompatibles - Rules et Custom Database Action Scripts uniquement), nous encourageons les clients qui utilisent Node 12 à rester à jour avec les versions de Node bénéficiant d’un support actif à long terme (LTS), pour des raisons de sécurité et de conformité. Les clients qui utilisent encore Node 8 ne respectent plus les exigences de conformité en matière de sécurité et doivent migrer vers Node 16 pour éliminer les risques de sécurité. Nous avons supprimé l’environnement d’exécution Node 8 le 22 févr. 2022 pour les locataires du Public Cloud, puis dans la version d’avril 2022 du Private Cloud. Après ces dates, les locataires toujours configurés pour utiliser Node 8 risquent une interruption de service.
Longueur fixe des jetons d’accès opaques et des codes d’autorisation
Obsolète : 7 octobre 2021 (Public Cloud), décembre 2021 (Private Cloud)Fin de vie : 12 avril 2022 (Public Cloud), 30 juin 2022 (Private Cloud)À compter du 12 avril 2022 dans le Public Cloud et de décembre 2021 dans le Private Cloud, les jetons d’accès et les codes d’autorisation seront émis avec des longueurs variables afin de respecter la spécification OAuth RFC6749 et d’éviter que les applications présument de la valeur des codes d’autorisation et des jetons d’accès. À l’heure actuelle, les jetons d’accès et les codes d’autorisation ont une longueur fixe. La longueur actuelle du code d’autorisation est inférieure à ce que recommandent certains spécialistes de la sécurité. Grâce à ce changement, Auth0 fournit un code et un jeton plus robustes tout en améliorant les performances de ses systèmes.Les clients dont les systèmes sont configurés pour dépendre d’une longueur précise des codes d’autorisation et des jetons d’accès doivent passer d’une configuration à longueur fixe à une configuration à longueur variable avant le 12 avril 2022 dans le Public Cloud ou la version de juin 2022 du Private Cloud.
Fin de vie de l’environnement d’exécution d’extensibilité Node.js v8
Obsolète : 15 avril 2020Fin de vie : 25 février 2022 (Cloud public), avril 2022 (version Private Cloud)À partir du 13 décembre 2019, Node.js v8 ne bénéficiait plus du support à long terme (LTS). Cela signifie que les correctifs de sécurité critiques n’étaient plus rétroportés vers cette version. Les clients qui utilisent encore Node 8 ne sont plus conformes aux exigences de sécurité et doivent migrer vers Node 12 pour éliminer les risques de sécurité. Pour en savoir plus sur la migration de la version Node de votre locataire de 8 à 12, consultez Migrer de Node.js 8 vers Node.js 12.Comme Node.js v12 sortira lui aussi du LTS en 2022, nous encourageons fortement tous les clients qui utilisent Rules et Hooks à migrer vers Actions avec Node 16 dès que possible, et avant la fin officielle de la prise en charge de Node 12 par la communauté Node.js le 30 avril 2022. Pour en savoir plus sur les étapes de migration requises, consultez Migrer Rules et Hooks vers Actions.
Obsolète : 05 mai 2021 (Public Cloud)Fin de vie : 03 novembre 2021 (Public Cloud)La périphérie réseau Legacy d’Auth0 cessera de fonctionner dans le Public Cloud. Après le 03 novembre 2021, les locataires du Public Cloud qui n’auront pas terminé la migration vers la nouvelle périphérie réseau d’Auth0 ne recevront plus de trafic. Tous les nouveaux sont automatiquement créés sur la nouvelle périphérie réseau.
Obsolescence des requêtes non paginées de Management API v2
Obsolète : 21 juillet 2020 (Public Cloud)Fin de vie : 26 janvier 2021 (Public Cloud), février 2022 (version Private Cloud)Après le 26 janvier 2021, les requêtes adressées aux points de terminaison Management API v2 suivants renverront un maximum de 50 éléments pour les locataires du Public Cloud. Pour récupérer plus d’éléments, vous devez inclure les paramètres page et per_page. À compter du 21 juillet 2020, Auth0 affichera les journaux du locataire et un commutateur de migration pour vous aider à vous préparer à ce changement.
Sont touchés tous les locataires du Public Cloud créés avant le 21 juillet 2020 qui appellent activement les points de terminaison touchés sans transmettre le paramètre per_page pour les requêtes pouvant renvoyer plus d’un résultat. Les locataires ne sont pas touchés s’ils ont été créés après le 21 juillet 2020, s’ils n’utilisent pas les points de terminaison touchés, s’ils utilisent les points de terminaison touchés en transmettant le paramètre per_page, ou s’ils 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 Management API v2.
Abandon de la fonctionnalité Custom Domain pour Private Cloud
Obsolète : 17 juin 2021Fin de vie : 20 décembre 2021Afin d’assurer l’uniformité de tous les déploiements Auth0 et de nous concentrer sur l’amélioration de la fonctionnalité Auth0 Custom Domain, nous mettrons fin à la fonctionnalité Custom Domain pour Private Cloud le 20 décembre 2021. Cette uniformité nous permettra d’améliorer la fonctionnalité et de corriger plus rapidement les problèmes de fiabilité, ce qui augmentera l’efficacité opérationnelle et permettra aux clients de tirer plus rapidement parti des domaines personnalisés.
Obsolète : 25 mai 2021Fin de vie : 01 décembre 2021Le 01 décembre 2021, le comportement de déconnexion changera pour toujours rediriger les utilisateurs vers l’URI transmise aux API de déconnexion d’Auth0, plutôt que d’utiliser le paramètre de requête returnTo transmis à /login/callback par les pendant l’exécution de la déconnexion. Si Auth0 n’a aucune trace d’un appel antérieur à l’une de ces API, la déconnexion s’effectuera, mais aucune redirection n’aura lieu et une page d’erreur s’affichera pour les utilisateurs finaux. Pour en savoir plus, consultez le guide de migration des redirections de déconnexion.
Dépréciation du rôle d’administrateur d’application dans l’Auth0 Dashboard
Obsolète : 01 février 2021Fin de vie : 30 septembre 2021 (Public Cloud), septembre 2021 (version mensuelle de Private Cloud)Auth0 modifie le contrôle d’accès basé sur les rôles dans l’Auth0 Dashboard. Le rôle d’administrateur d’application, tel qu’il est défini aujourd’hui, devient obsolète. Après le 01 février 2021, les administrateurs ne pourront plus inviter de membres avec le rôle obsolète d’administrateur d’application. Les administrateurs d’application existants pourront continuer à utiliser l’Auth0 Dashboard avec l’ensemble d’autorisations actuel jusqu’à la date de fin de vie.Un nouvel ensemble de rôles pour l’Auth0 Dashboard est offert afin d’améliorer la collaboration entre les membres de l’équipe et de la rendre plus sécuritaire, y compris des rôles de lecteur et d’éditeur avec un accès limité. Un nouveau rôle Editor - Specific Apps remplace l’ancien rôle Application Administrator pour les forfaits d’abonnement qui prennent en charge les rôles d’éditeur.Vos locataires seront touchés par cette dépréciation si les critères suivants sont remplis :
Créés avant le 01 février 2021
Ont au moins un membre du locataire ayant le rôle Application Admin
N’ont pas activé l’aperçu de la fonctionnalité des rôles de l’Auth0 Dashboard
Obsolète : 19 janvier 2021Fin de vie : 10 mai 2021 (Public Cloud), version de juin de Private Cloud (v2106)À compter du 10 mai 2021 pour Public Cloud et de la version de juin de Private Cloud (v2106), la périphérie réseau d’Auth0 n’acceptera plus le trafic TLS 1.0 ni TLS 1.1. Ces anciens protocoles ne sont pas sécurisés et comportent des faiblesses et des vulnérabilités bien connues dans l’industrie. Pour une sécurité maximale, toutes les applications Auth0 doivent passer à TLS 1.2 ou à une version ultérieure. Les détails exacts et les étapes requises varient selon votre application.
Obsolescence : janvier 2018Fin de vie : janvier 2021Auth0 a déclaré obsolète l’utilisation de la bibliothèque auth0-analytics.js, qui ajoute l’intégration de Facebook et de Google Analytics à Lock. Elle écoute les événements de Lock et les transmet à la bibliothèque Auth0-tag-manager.js. Elle peut encore fonctionner dans certains cas hérités. Cette bibliothèque n’est plus maintenue. Vous devrez peut-être écrire du code personnalisé pour utiliser auth0-tag-manage.js afin de gérer les requêtes proxy vers des bibliothèques d’analyse tierces comme Facebook, X et Google.
Obsolescence des métadonnées des identifiants d’appareil sans user_id
Obsolète : 31 août 2020Fin de vie : 17 décembre 2020Auth0 exige maintenant que vous fournissiez le user_id lorsque vous utilisez le point de terminaison GET /api/v2/device-credentials. Si votre requête n’inclut pas de user_id, elle renverra un code d’état 400. Vérifiez la depnote dans les journaux de votre locataire pour voir si vous êtes touché par cette obsolescence. Pour en savoir plus, consultez Vérifier les erreurs d’obsolescence.Auth0 a identifié les locataires touchés par cette obsolescence et a contacté les administrateurs de ces locataires. Si votre locataire envoie actuellement des requêtes sans user_id, vous devriez apporter ce changement dès que possible.
Obsolescence de la vérification du courriel pour Azure AD/ADFS
Obsolète :
Public Cloud : 18 novembre 2020
Private Cloud : 1er décembre 2020
Fin de vie :
Public Cloud : 18 mai 2021
Private Cloud : version de juin de Private Cloud (v2106)
Auth0 définissait auparavant le champ email_verified sur true pour les connexions Azure AD et ADFS. Si vous utilisiez des connexions Azure AD/ADFS avant cette date d’obsolescence, vous disposez d’un paramètre de locataire qui remplace le paramètre de connexion pour la vérification du courriel et conserve le comportement précédent.Le 18 mai 2021 dans Public Cloud, ainsi que dans la version de juin de Private Cloud (v2106), Auth0 commencera à utiliser la propriété au niveau de la connexion pour toutes les connexions Azure AD/ADFS. Vous devriez vous assurer que toutes vos connexions sont correctement configurées avant cette date. Pour en savoir plus, consultez Email Verification for Azure AD and ADFS.
Entrée en vigueur : février 2020Google Chrome v80 modifie la façon dont il gère les cookies. Dans ce contexte, Auth0 apportera les modifications suivantes à sa gestion des cookies :
Les cookies sans l’attribut samesite défini seront réglés sur lax
Les cookies avec sameSite=none doivent être sécurisés, sinon ils ne pourront pas être enregistrés dans le stockage des cookies du navigateur
L’objectif de ces modifications est d’améliorer la sécurité et d’aider à atténuer les attaques CSRF. Pour en savoir plus, consultez sameSite Cookie Attribute Changes.
Obsolète : 10 novembre 2018Fin de vie : 30 juin 2019 (Public Cloud), mai 2021 (version mensuelle de Private Cloud)Pour Public Cloud, User Search v2 a été déclaré obsolète, et vous auriez dû prendre les mesures nécessaires avant le 30 juin 2019. Des notifications ont été envoyées aux clients qui devaient effectuer cette migration.Pour Private Cloud, les points de terminaison User Search v1 et v2 ne seront plus disponibles après la version mensuelle de mai de Private Cloud et ont été remplacés par le nouveau point de terminaison User Search v3.
Obsolescence du point de terminaison Passwordless pour les applications confidentielles
Auth0 a rendu obsolète l’utilisation du point de terminaison /passwordless/start par des applications confidentielles lorsqu’Auth0 ne peut pas vérifier que l’appel est effectué au nom de l’application. Pour en savoir plus, consultez Migrer vers le point de terminaison Passwordless pour les applications confidentielles.Modifications de la protection contre le détournement de clics pour Pour prévenir le détournement de clics, si vous affichez votre page de connexion dans un iframe, Auth0 a ajouté une option d’activation permettant d’ajouter des en-têtes, que nous vous recommandons fortement d’activer. Pour en savoir plus, consultez Modification de la protection contre le détournement de clics pour Universal Login.
Obsolescence: 08 juillet 2017Fin de vie: à déterminerDepuis le 08 juillet 2017, Auth0 a déclaré le point de terminaison/oauth/ro obsolète pour les connexions par mot de passe et . Vous pouvez maintenant obtenir la même fonctionnalité à l’aide du point de terminaison /oauth/token. Pour en savoir plus, consultez Migration du flux Resource Owner Password.
Management API v1 atteindra sa fin de vie dans le Cloud public le 13 juillet 2020. Management API v1 sera incluse dans le Cloud privé jusqu’à la version mensuelle de novembre 2020, qui sera la première à ne pas inclure Management API v1. Il se peut que vous deviez intervenir avant cette date pour éviter toute interruption de service. Des avis ont été envoyés et continueront de l’être aux clients qui doivent effectuer cette migration.
Obsolète : 05 mars 2020Fin de vie : 31 mars 2020Facebook a annoncé que, le 31 mars 2020, il désactiverait les anciennes API d’Instagram et ne fournirait aucune solution de rechange pour mettre en place la connexion avec Instagram. Pour en savoir plus, consultez Obsolescence de la connexion Instagram.
Obsolète : 1 mars 2020Fin de vie : 1 mars 2020Yahoo a modifié la façon de récupérer le profil de l’utilisateur ainsi que les renseignements qu’il contient. Pour en savoir plus, consultez Changements apportés à l’API Yahoo.
Obsolescence : 11 avril 2019Fin de vie : 11 avril 2019Depuis le 11 avril 2019, Google a déclaré Google Cloud Messaging (GCM) obsolète et l’a remplacé par Firebase Cloud Messaging (FCM). Pour en savoir plus, consultez Migration de Google vers Firebase Cloud Messaging.
Obsolescence : 30 avril 2019Fin de vie : 30 juillet 2019Le 30 avril 2019, Facebook a déclaré obsolète l’utilisation du champ Social Context pour les nouvelles applications. Pour en savoir plus, consultez Obsolescence du champ Social Context de Facebook.
Obsolescence : 1er août 2018Fin de vie : Graph API v3 publiée le 8 janvier 2019À compter du 1er août 2018, Facebook a modifié les autorisations et les champs pouvant être demandés dans l’API Graph de Facebook. Auth0 a mis à jour les connexions Facebook pour tenir compte de ces changements et a modifié l’interface de la connexion afin d’en améliorer la clarté. Consultez Facebook Login Changelog: Recent Changes to Facebook Login pour obtenir tous les détails et les dates clés. Pour en savoir plus, consultez Changements apportés à l’API Graph de Facebook.
Nous améliorons continuellement la sécurité de notre service. Dans le cadre de cet effort, nous avons déclaré l’API Legacy Lock obsolète, laquelle comprend les points de terminaison /usernamepassword/login et /ssodata. Ces points de terminaison sont utilisés par Lock.js v8, v9 et v10 ainsi que par Auth0.js v6, v7 et v8, et peuvent aussi être appelés directement par les applications.Depuis le 6 août 2018, Auth0 a désactivé de façon permanente l’API Legacy Lock. Cette suppression du service atténue entièrement la vulnérabilité CSRF divulguée en avril 2018. Elle met aussi fin à la période de grâce précédant le retrait complet, annoncée initialement le 16 juillet 2018, ce qui signifie que l’API Legacy Lock ne peut plus être réactivée.Si la migration de votre API Legacy Lock n’est pas encore terminée, vos utilisateurs pourraient subir une interruption de service, des échecs de connexion ou d’autres effets indésirables. Vous devrez terminer votre migration afin de rétablir le fonctionnement normal. Consultez les erreurs liées à l’obsolescence pour identifier la ou les sources de toute erreur, dans les journaux de votre locataire, liée aux mises en obsolescence.
Si vous implémentez actuellement la connexion dans votre application avec Lock v8, v9 ou v10, ou Auth0.js v6, v7 ou v8, vous êtes concerné par ces changements. Vous l’êtes également si votre application appelle directement les points de terminaison /usernamepassword/login ou /ssodata via l’API.Nous recommandons aux applications qui utilisent Universal Login de mettre à jour les versions des bibliothèques utilisées dans la page de connexion.Cependant, les applications qui utilisent Lock ou Auth0.js de façon intégrée, ou qui appellent directement les points de terminaison d’API concernés, doivent être mises à jour; les applications qui utilisent encore des points de terminaison obsolètes cesseront de fonctionner correctement après la date de retrait du service.Les bibliothèques et SDK qui ne sont pas explicitement mentionnés ici ne sont pas concernés par cette migration.
Professional (anciennement Developer Pro) : 20 août 2019
Enterprise : 04 novembre 2019
Afin d’offrir à nos clients la solution la plus fiable et la plus évolutive, Auth0 a rendu obsolète Tenant Logs Search Engine v2 au profit de v3. Auth0 migre de façon proactive les clients qui ne sont pas touchés par ce changement, tandis que ceux qui pourraient l’être sont avisés afin d’opter pour v3 pendant la période de grâce prévue. Pour en savoir plus, consultez Migrer de Tenant Log Search v1 vers v2.
Nouvelles adresses IP à ajouter à la liste d’autorisation en Australie
À compter du 30 septembre 2017, Auth0 a mis à jour ses environnements infonuagiques, et le trafic en provenance de l’Australie provient désormais de nouvelles adresses IP. Si vous utilisez une liste d’autorisation d’adresses IP, vous devrez ajouter ces nouvelles adresses à vos règles de pare-feu.
Si vous utilisez une connexion de base de données personnalisée, une Rule ou un fournisseur de courriel personnalisé connecté à votre environnement, et que vous avez mis en place des restrictions de pare-feu pour des plages d’adresses IP, vous êtes concerné par ce changement. Vous devrez vous assurer que les adresses IP suivantes sont autorisées 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
Nouvelles adresses IP pour la liste d’autorisation en Europe
À compter du 30 septembre 2017, Auth0 a mis à jour ses environnements infonuagiques, et le trafic provenant d’Europe utilise de nouvelles adresses IP. Si vous utilisez une liste d’autorisation d’adresses IP, vous devrez ajouter ces nouvelles adresses à vos règles de pare-feu.
Si vous utilisez une connexion de base de données personnalisée, une Rule ou un fournisseur de courriel personnalisé connecté à votre environnement, et que vous avez mis en place des restrictions de pare-feu pour certaines plages d’adresses IP, vous êtes concerné par ce changement. 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
Migration du fournisseur de CDN dans les environnements d’Europe et d’Australie
Depuis le 12 juillet 2017, Auth0 a amélioré l’évolutivité et la disponibilité de son CDN. Nous utilisons désormais Amazon CloudFront. Nous avons déjà apporté ce changement dans l’environnement américain et sommes maintenant prêts à le déployer en Europe et en Australie.
Vous êtes concerné si vous utilisez Lock (hébergé sur notre CDN) en Europe ou en Australie. Ce changement ne devrait entraîner ni interruption ni modification du comportement de vos applications; vous n’avez donc rien à faire. Cet avis est fourni à titre informatif seulement.
Migration des Rules pour l’échange de mot de passe et de jeton d’actualisation
Le 31 mai 2017, dans le cadre des efforts d’Auth0 pour améliorer la sécurité, nous avons ajouté la possibilité d’exécuter des Rules lors de l’échange Password Grant du pour le (échange de mot de passe), ainsi que lors de l’échange de jeton d’actualisation.
Vous utilisez cette fonctionnalité 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 Rules sont définies dans Auth0 Dashboard. Afin d’assurer une transition harmonieuse, nous avons désactivé l’exécution des Rules pour ces échanges précis dans votre locataire. Ces Rules s’exécuteront désormais pour tous les nouveaux clients, ainsi que pour les clients qui n’ont pas encore utilisé ces échanges.Vous pouvez ajouter de la logique à vos Rules pour modifier leur comportement pour ces échanges en vérifiant la propriété context.protocol :
oauth2-password indique l’échange par mot de passe (et password-realm)
oauth2-refresh-token indique l’échange de Jeton d’actualisation
Si vous souhaitez activer le nouveau comportement sur ce locataire à des fins de test avant la date limite d’adhésion obligatoire, connectez-vous à Auth0 Dashboard et activez le bouton bascule Exécuter les Rules sur les échanges par mot de passe et de Jeton d’actualisation dans Paramètres du locataire > Avancé.
Le 1er mars 2017, dans le cadre des efforts d’Auth0 pour renforcer la sécurité et la conformité aux normes, nous avons cessé de prendre en charge la liaison de comptes dans le rappel d’autorisation (c’est-à-dire l’acceptation d’un jeton d’accès dans l’appel authorize).
Si vous avez reçu une notification par courriel à ce sujet, vous êtes concerné par ce changement. Lorsque vous mettez à jour vos applications pour utiliser la Management API afin de lier des comptes, vous pouvez vérifier si vous êtes toujours concerné en recherchant des avertissements dans les journaux de votre locataire. Ces entrées seront consignées si vous envoyez un Jeton d’accès dans vos appels à authorize.
À compter du 20 février 2017, Auth0 a étendu sa présence à de nouvelles régions aux États-Unis, et le trafic provenant de ces régions utilisera de nouvelles adresses IP. Si vous autorisez des adresses IP, vous devrez ajouter ces nouvelles adresses à vos règles de pare-feu.
Si vous utilisez une connexion de base de données personnalisée, une Rule et/ou un fournisseur de courriel personnalisé connecté à votre environnement, et que vous avez mis en place des restrictions de pare-feu pour des plages d’adresses IP, vous êtes concerné par ce changement. Vous devrez ajouter les adresses IP suivantes à vos règles de 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
Processus vulnérable de réinitialisation du mot de passe
Avant le 1er février 2017, le processus de réinitialisation du mot de passe d’Auth0 permettait à un utilisateur de saisir son courriel et un nouveau mot de passe. Cela déclenchait l’envoi d’un courriel de confirmation demandant à l’utilisateur de confirmer qu’il avait bien demandé une réinitialisation du mot de passe.
Le problème est qu’un utilisateur pourrait cliquer par inadvertance sur le lien de confirmation, ce qui permettrait à un attaquant de modifier le mot de passe de l’utilisateur.La version 9 de Lock et les versions ultérieures utilisent exclusivement le nouveau flux de réinitialisation du mot de passe. Lock 8 et les versions antérieures ne prennent pas en charge ce nouveau flux. Nous vous recommandons fortement de passer à Lock 9 ou à une version ultérieure dès que possible.
Même si vous n’utilisez pas Lock, le flux de réinitialisation vulnérable est accessible directement par l’API. (Consultez le point de terminaison /dbconnections/change_password pour en savoir plus.) Auth0 vous recommande fortement de modifier sans délai toute application qui utilise le flux actuel afin de passer au nouveau flux de réinitialisation et d’activer cette migration.
Paramètre state requis lors d’une redirection depuis une Rule
À compter du 6 décembre 2016, lorsqu’une redirection est effectuée depuis une Rule Auth0, Auth0 génère et envoie un paramètre state dans la requête HTTP et vérifie qu’un paramètre state valide est présent lorsque le flux revient au point de terminaison /continue. Le site vers lequel la redirection est envoyée doit récupérer la valeur du paramètre state et la renvoyer en l’ajoutant comme paramètre au moment du retour vers le point de terminaison /continue.
Vous n’êtes concerné par ce changement que si vous effectuez une redirection depuis Rules et que vous ne capturez pas encore le paramètre state pour le renvoyer au point de terminaison /continue.
Modification du point de terminaison de suppression de tous les utilisateurs
Avant le 13 septembre 2016, le point de terminaison utilisé pour supprimer tous les utilisateurs était DELETE /api/v2/users. Il était semblable au point de terminaison permettant de supprimer un seul utilisateur : DELETE /api/v2/users. Pour éviter les requêtes accidentelles vers le point de terminaison de suppression de tous les utilisateurs, l’URL a été remplacée par DELETE /api/v2/allusers. Cela devrait garantir que seules des requêtes intentionnelles sont envoyées à ce point de terminaison.
Vous n’êtes concerné par ce changement que si vous utilisez actuellement le point de terminaison de suppression de tous les utilisateurs. Dans ce cas, la seule modification à apporter consiste à changer l’URL, comme expliqué ci-dessus.
Changements apportés à la personnalisation des modèles d’envoi de courriels
À compter du 29 août 2016, le fournisseur de courriel intégré d’Auth0 ne sera plus pris en charge dans un environnement de production. Les courriels envoyés au moyen du fournisseur Auth0 ne pourront plus être personnalisés. Ils seront limités au modèle fourni, et vous ne pourrez pas modifier l’adresse de l’expéditeur ni l’objet.Le service de courriel intégré peut encore être utilisé à des fins de test, mais vous devez passer à un service tiers pris en charge par Auth0 (Amazon SES, Mailchimp, SendGrid ou un autre fournisseur fondé sur SMTP) avant de mettre vos applications en production. Si vous utilisez déjà un fournisseur de courriel personnalisé, aucune action n’est requise.
Jetons d’accès du fournisseur d’identité supprimés du profil utilisateur et du jeton d’identité
À compter du 8 août 2016, le format de l’objet JSON du profil utilisateur (jeton d’identité) renvoyé par l’Authentication API d’Auth0 a été modifié afin de retirer le jeton d’accès du fournisseur d’identité qui figurait dans le tableau identities du profil utilisateur.Pour obtenir le jeton d’accès du fournisseur d’identité d’un utilisateur, vous devrez effectuer une requête HTTP GET vers le point de terminaison /api/v2/users/{user-id} en fournissant un jeton d’API généré avec le scope read:user_idp_tokens. Vous aurez toujours accès au jeton d’accès du fournisseur d’identité dans l’argument user des Rules Auth0.
Vous êtes concerné par ce changement seulement si vous utilisez le jeton d’accès du fournisseur d’identité (identities[0].access_token dans le profil de l’utilisateur) en dehors des Rules pour appeler d’autres services du fournisseur d’identité (comme l’API Graph de Facebook, les API Google, etc.). Si votre locataire a été créé après ce changement, la mise à jour sera effectuée automatiquement.
À compter du 1er juin 2016, lors de l’appel au point de terminaison Tokeninfo, l’URL de l’appel d’API (par exemple https://{yourDomain}/) doit correspondre à la valeur de l’attribut iss de l’ID Token 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 de l’ID Token à valider correspond à l’espace de noms de votre locataire Auth0 : https://{yourDomain}/. Vous pouvez utiliser jwt.io pour décoder le jeton et confirmer la valeur de l’attribut iss.
Changements à l’adresse d’expédition des courriels
Le 27 avril 2016, le fournisseur de courriel intégré d’Auth0 a commencé à envoyer tous les courriels à partir d’une adresse d’expéditeur prédéfinie (no-reply@auth0user.net). Les fournisseurs de courriel personnalisés sont désormais gratuits. Pour personnaliser l’adresse d’expéditeur, vous pouvez utiliser un service tiers pris en charge par Auth0 (Amazon SES, Mailchimp, SendGrid) ou un autre fournisseur fondé sur SMTP. Si vous utilisez déjà un fournisseur de courriel personnalisé, rien ne changera.
Les points de terminaison PATCH et POST n’acceptent plus l’indicateur secret_encoded
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érera ni n’acceptera plus de secrets d’application encodés en base64 pour les nouvelles applications.Les applications existantes dont des secrets encodés sont déjà stockés resteront intactes et inchangées, mais les nouvelles applications n’utiliseront plus l’encodage base64. Par conséquent, l’indicateur secret_encoded n’est plus accepté ni nécessaire.
Authentification
Gérer les utilisateurs
Personnaliser
Auth0 AI
Plateforme