Propriétés protégées dans les connexions sociales non personnalisées
Déprécié : 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 ni 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 de mise en œuvre est entièrement géré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 comme 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 par la Management API
Déprécié : 11 février 2025Fin de vie : 19 août 2025Le point de terminaison Mettre à jour un utilisateur (PATCH /api/v2/users/{id}) de la 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
Déprécié : 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 initiale.Depuis leur création, la grande majorité de nos environnements de cloud privé et certains de nos environnements de cloud public imposent déjà l’utilisation du SNI. Par exemple, les environnements de cloud public 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 Déploiement de fin de vie pour l’utilisation obligatoire du SNI pour les requêtes HTTPS.
Utilisez toujours HTTPS pour communiquer avec Auth0
Déprécié : 4 septembre 2024Fin de vie : 4 octobre 2024À compter du 4 octobre 2024, Auth0 ne redirigera plus automatiquement les requêtes API utilisant le protocole 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 : mise à jour de l’attribution des rôles pour exiger le scope Create
Deprecated : 7 mars 2024End of life : 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 permissions prévues par ce scope.Auparavant, des rôles pouvaient être attribués aux utilisateurs avec le scope read:roles.
Mettre à jour les applications qui utilisent l’authentification inter-origines
Déprécié : 25 avril 2024Fin de vie : 10 octobre 2024Les nouvelles applications créées dans Auth0 auront l’authentification inter-origines désactivée par défaut. Les requêtes adressées à certains points de terminaison de la Management API (Récupérer les clients, Récupérer le client par ID) devront être modifiées pour utiliser cross_origin_authentication.
Retirer l’accès aux Subscription Tickets pour les administrateurs de tenant
Déprécié : 5 juin 2024Fin de vie : 5 août 2024L’accès aux Subscription Tickets dans l’Auth0 Support Center changera le 5 août 2024. Pour conserver l’accès permettant de consulter et de gérer tous les tickets de soutien créés par l’ensemble des utilisateurs d’un tenant, le nouveau rôle Elevated Support Access est requis.
Dépréciation des liens de réinitialisation du mot de passe et de vérification du courriel dans les journaux du tenant
Déprécié : 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 tenant. Vous pouvez récupérer ces liens dans la réponse à la requête de réinitialisation du mot de passe ou de vérification du courriel de l’.
Réduction de la durée de vie maximale des transactions de connexion
Déprécié : 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 vie maximale d’une heure pour les flux de connexion basés sur la redirection. Les flux de connexion qui prennent plus d’une heure à se terminer expireront dans Universal et Classic Login. Après expiration, toute action subséquente dans le navigateur de l’utilisateur final (p. ex., saisir l’adresse courriel ou le mot de passe, être redirigé de nouveau 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 une nouvelle transaction de connexion;
une page d’erreur si la route de connexion par défaut n’est pas configurée.
Dépréciation des portées non enregistrées dans les jetons d’actualisation
Déprécié : 12 juillet 2023Fin de vie : 17 janvier 2024Nous améliorons l’évaluation des portées lors de l’échange de afin d’empêcher la demande de portées non enregistrées. Les valeurs de portée personnalisées qui ne sont pas enregistrées pour la valeur aud ou audience (pour une API enregistrée dans votre tenant) sont considérées comme des portées non enregistrées.Avec ce changement, l’évaluation des portées de l’API inclura toutes les portées personnalisées demandées lors de l’authentification de l’utilisateur ou injectées par l’extensibilité, comme les Rules. Cette évaluation validera que toutes les portées sont enregistrées et renverra une erreur si l’une d’elles ne l’est pas.
Dépréciation des dépôts auth0-cordova, angular-auth0 et express-oauth2-bearer
Déprécié : 27 avril 2023Fin de vie : 30 juin 2023 (express-oauth2-bearer), 27 octobre 2023 (angular-auth0 et auth0-cordova)Nous avons déprécié les dépôts suivants :
Ces bibliothèques ne seront plus prises en charge. Veuillez les retirer de tous les projets actifs 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 mission de prendre en charge toutes les futures versions LTS de Node.js par l’entremise des Actions, et afin de rester en phase avec la communauté des développeurs Node.js, nous lançons Node 18 alors que Node 16 est toujours en Active LTS. Nous encourageons vivement tous nos clients à passer dès aujourd’hui à Node 18 pour tirer pleinement parti de son cycle LTS. N’oubliez pas que, même si Node 16 LTS demeure offert jusqu’en septembre, son utilisation peut comporter certains risques une fois le cycle LTS terminé; nous vous recommandons donc de passer à Node 18.Node.js 18 est maintenant disponible de façon générale (GA) dans l’ensemble de notre offre d’extensibilité. Cela comprend les Actions, Rules, Hooks, les scripts de base de données et les Custom Social Connections. Nous encourageons fortement tout le monde à 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é
Déprécié : 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 Custom Database Scripts au moyen d’un module Node.js appelé edge.js.La dépréciation 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 essentielle au maintien d’une plateforme performante et sécurisée pour exécuter du code non fiable. Ce changement nous permettra de continuer à améliorer notre offre d’extensibilité de prochaine génération.
Pour en savoir plus, consultez Migrer depuis les fonctionnalités d’extensibilité edge.js.
Prise en charge de oracledb dans les fonctionnalités d’extensibilité
Déprécié : 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 la connexion aux bases de données Oracle à partir de Node.js dans les fonctionnalités d’extensibilité. Auth0 prenait auparavant en charge la connexion aux bases de données Oracle à partir du code d’extensibilité pour les Rules, Hooks et Custom Database Scripts au moyen d’un module Node.js appelé oracledb.L’abandon de la prise en charge de la connexion aux bases de données Oracle à partir de Node.js dans les fonctionnalités d’extensibilité est essentiel pour maintenir une plateforme performante et sécurisée pour l’exécution de code non fiable. Ce changement nous permettra de continuer à améliorer nos offres d’extensibilité de nouvelle génération.Pour en savoir plus, consultez Migrer depuis les fonctionnalités d’extensibilité oracledb.
Fournisseur de revendications Auth0 pour SharePoint 2010 / 2013
Déprécié : 31 janvier 2023Fin de vie : 31 juillet 2023Auth0 n’offrira plus de soutien pour le module complémentaire auth0-claims-provider de 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 checkpoint pour le point de terminaison Get Role Users
Déprécié : 9 novembre 2022Fin de vie : 9 mai 2023Pour améliorer les performances, le point de terminaison de la Management API Get Role Users ne renverra plus de 1 000 résultats au total que si la méthode de pagination par checkpoint 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 par offset sera limitée à 1 000 résultats.Pour en savoir plus sur la mise en œuvre de ces deux méthodes de pagination, consultez la documentation de la Management API pour le point de terminaison Get Role Users.
Déprécié : 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 dans Public Cloud et du 18 avril 2023 dans Private Cloud, Auth0 autorisera l’ajout de revendications 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 revendications avec espace de noms sur les jetons d’accès et les au moyen du code d’extensibilité (Rules / Hooks / Actions). La migration vers les revendications personnalisées permet d’ajouter des revendications personnalisées privées sans espace de noms et des revendications de profil utilisateur OIDC aux ; les jetons ID prennent actuellement en charge les revendications de profil utilisateur et prendront aussi en charge les revendications personnalisées privées sans espace de noms. Ces revendications seront également ajoutées à la réponse /userinfo d’Auth0. Pour commencer la migration, consultez le guide de migration des revendications personnalisées.Si votre tenant exécute du code d’extensibilité (Rules / Hooks / Actions) qui tente de définir des revendications personnalisées sans espace de noms qui ont été ignorées jusqu’à cette obsolescence, ces revendications commenceront alors à apparaître dans les jetons et la réponse /userinfo. Nous vous recommandons d’examiner votre configuration et les journaux d’Auth0.Avec l’ajout de revendications privées sans espace de noms, Auth0 applique les restrictions suivantes qui pourraient avoir une incidence sur votre tenant :
Auth0 limitera la charge utile des revendications personnalisées à un maximum de 100KB.
Auth0 limitera la personnalisation ou la modification des revendications standard ou des revendications utilisées à l’interne par Auth0.
À l’avenir, Auth0 pourrait limiter l’utilisation d’autres revendications ne figurant pas dans la liste ci-dessus. Le cas échéant, les clients seront avisés dans un délai raisonnable afin d’effectuer la migration.
Auth0 limitera la création de revendications personnalisées privées sans espace de noms sur les jetons d’accès avec une Auth0, à l’exclusion du point de terminaison /userinfo.
Seules les revendications de profil utilisateur OIDC spécifiées peuvent être ajoutées aux jetons d’accès.
Auth0 limitera la création de toute revendication personnalisée commençant par le caractère $.
Déprécié : 13 juin 2022Fin de vie : 31 janvier 2023Nous améliorons l’infrastructure sous-jacente sur laquelle repose Auth0 Private Cloud en y introduisant une pile technologique moderne fondée sur Kubernetes, ainsi que des mises à niveau de la base de données. Nous travaillons actuellement avec tous les clients d’Auth0 Private Cloud afin de planifier, au cours de cette année, la mise à niveau de leur déploiement Private Cloud vers la nouvelle infrastructure, et nous mettrons l’ancienne hors service le 31 janvier 2023.De plus, 2205 (version de mai 2022) est la dernière version officielle de l’ancienne plateforme Private Cloud. Les bogues et les vulnérabilités de sécurité seront évalués et corrigés au besoin dans des versions comprenant des correctifs. Avant la mise à niveau vers la nouvelle infrastructure, les environnements devront être mis à jour vers la version minimale compatible afin de permettre cette migration.Veuillez communiquer avec votre responsable technique de compte pour toute question.
Déprécié : 4 mai 2022 (Public Cloud), 9 juin 2022 (version 2205 du Private Cloud)Fin de vie : 2 mai 2023 (Public Cloud), 6 janvier 2023 (Private Cloud)À compter du 4 mai 2022 dans le Public Cloud et du 9 juin 2022 dans le Private Cloud, les extensions de logs Auth0 suivantes seront dépréciées :
Auth0 Authentication API Webhooks
Auth0 Management API Webhooks
Logs to Cloudwatch
Logs to Logentries
Logs to Loggly
Logs to Logstash
Logs to Papertrail
Logs to Splunk
Logs to Sumo Logic
Déprécié : 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 le Public Cloud et du 21 décembre 2022 dans le Private Cloud, les extensions de logs Auth0 suivantes seront dépréciées :
Logs to Segment
Logs to Mixpanel
Logs to AppInsights
Logs to Azure Blob Storage
Toutes les extensions de logs énumérées ci-dessus sont maintenant dépréciées. Vous pouvez configurer une fonctionnalité équivalente à l’aide des flux d’événements de logs ou d’intégrations dans le Auth0 Marketplace. À compter du 2 novembre 2022 dans le Public Cloud et du 21 décembre 2022 dans le Private Cloud, Auth0 n’offrira plus de soutien pour les extensions de logs installées figurant dans la liste ci-dessus. Pour en savoir plus, consultez Migrate from Log Extensions.
déprécié : 9 décembre 2021 et décembre 2021 (Private Cloud Release 2112.2)End of life : 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 de tenant au processus d’identification de l’Authentication API. Lorsqu’une requête est envoyée, l’Authentication API validera l’identifiant de l’entité (p. ex. : client_id) du tenant demandeur ainsi que le nom du tenant dans le domaine de l’URL. Le tenant propriétaire de 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 tenant demandeur 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 d’une Enterprise connection)
Fin de vie : 30 avril 2022Le 30 avr. 2022, Node.js v12 est arrivé à la fin de sa période de soutien à 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 migre de Node 12 à Node 16.Bien que la mise à jour vers Node 16 n’apporte aucun changement incompatible dans la bibliothèque standard de Node.js (Rules et Custom Database Action Scripts sont touché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 actives de Node bénéficiant du soutien à long terme (LTS), pour des raisons de sécurité et de conformité. Les clients qui utilisent encore Node 8 ne sont plus conformes aux exigences de sécurité et doivent migrer vers Node 16 afin d’éliminer les risques de sécurité. Nous avons retiré le runtime Node 8 le 22 févr. 2022 pour les tenants Public Cloud, puis dans la version d’avril 2022 de Private Cloud. Après ces dates, les tenants toujours configurés pour Node 8 risquent une interruption de service.
Longueur fixe des jetons d’accès opaques et des codes d’autorisation
Déprécié: 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 Public Cloud et de la version de décembre 2021 de Private Cloud, les jetons d’accès et les codes d’autorisation seront émis avec des longueurs variables afin de prendre en charge la spécification OAuth RFC6749 et d’éviter que les applications clientes ne présument de la valeur des codes d’autorisation et des jetons d’accès. À l’heure actuelle, la taille des jetons d’accès et des codes d’autorisation est fixe. La taille actuelle du code d’autorisation est inférieure à celle recommandée par 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 s’appuyer sur une longueur précise des codes d’autorisation et des jetons d’accès doivent passer de configurations à longueur fixe à des configurations à longueur variable avant le 12 avril 2022 dans Public Cloud ou la version de Private Cloud du 30 juin 2022.
Déprécié : 15 avril 2020Fin de vie : 25 février 2022 (Public Cloud), avril 2022 (version Private Cloud)À compter du 13 décembre 2019, Node.js v8 n’était plus pris en charge dans le cadre du soutien à 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 façon de migrer la version de Node pour l’ensemble du tenant de 8 à 12, consultez Migrer de Node.js 8 à Node.js 12.Comme Node.js v12 arrive lui aussi à la fin de son soutien à long terme 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 que la prise en charge de Node 12 ne prenne officiellement fin au sein de 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.
Déprécié : 05 mai 2021 (Public Cloud)Fin de vie : 03 novembre 2021 (Public Cloud)L’ancienne périphérie réseau d’Auth0 cessera de fonctionner sur Public Cloud. Après le 03 novembre 2021, les tenants de Public Cloud qui n’auront pas effectué leur 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.
Dépréciation des requêtes non paginées vers Management API v2
Déprécié : 21 juillet 2020 (Public Cloud)Fin de vie : 26 janvier 2021 (Public Cloud), février 2022 (version de Private Cloud)Après le 26 janvier 2021, les requêtes vers les points de terminaison Management API v2 suivants renverront un maximum de 50 éléments pour les tenants 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 tenant et une bascule de migration pour vous aider à vous préparer à ce changement.
Tous les tenants Public Cloud créés avant le 21 juillet 2020 sont concernés s’ils appellent activement les points de terminaison touchés sans transmettre le paramètre per_page pour des requêtes pouvant renvoyer plus d’un résultat. Les tenants ne sont pas concernés s’ils ont été créés après le 21 juillet 2020, n’utilisent pas les points de terminaison touchés, utilisent les points de terminaison touchés en transmettant le paramètre per_page, ou effectuent des requêtes qui renvoient toujours un seul résultat. Pour en savoir plus, consultez Migrate to Management API v2 Endpoint Paginated Queries.
Déprécié : 17 juin 2021Fin de vie : 20 décembre 2021Afin d’assurer une uniformité entre tous les déploiements Auth0 et de nous concentrer sur l’amélioration de la fonctionnalité Auth0 Custom Domain, nous mettrons fin à la fonctionnalité Private Cloud Custom Domain le 20 décembre 2021. Cette uniformité nous permet d’améliorer la fonctionnalité et de corriger plus rapidement les problèmes de fiabilité, ce qui accroît l’efficacité opérationnelle et permet aux clients de profiter plus rapidement des domaines personnalisés.
Déprécié : 25 mai 2021Fin de vie : 01 décembre 2021Le 1er décembre 2021, le comportement de la déconnexion changera afin de toujours rediriger les utilisateurs vers l’URI transmise aux API de déconnexion d’Auth0, au lieu d’utiliser le paramètre de requête returnTo transmis par les à /login/callback pendant la déconnexion. Si Auth0 n’a aucune trace d’une requête antérieure à l’une de ces API, la déconnexion se terminera, mais la redirection n’aura pas 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écié : 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 du Dashboard. Le rôle d’administrateur d’application, tel qu’il est défini aujourd’hui, est déprécié. Après le 01 février 2021, les administrateurs ne pourront plus inviter de membres avec le rôle déprécié d’administrateur d’application. Les administrateurs d’applications existants pourront continuer à utiliser le Dashboard avec l’ensemble actuel de permissions jusqu’à la date de fin de vie.Un nouvel ensemble de rôles du 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 à accès limité. Un nouveau rôle Editor - Specific Apps remplace l’ancien rôle Application Administrator pour les forfaits qui prennent en charge les rôles d’éditeur.Vos tenants seront touchés par cette dépréciation si les critères suivants sont respectés :
Créés avant le 01 février 2021
Ont au moins un tenant member ayant le rôle Application Admin
N’ont pas activé l’aperçu de la fonctionnalité des rôles du Dashboard
Déprécié : 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), le point d’entrée réseau d’Auth0 n’acceptera plus le trafic TLS 1.0 ni TLS 1.1. Ces anciens protocoles ne sont pas sécuritaires et présentent des faiblesses et des vulnérabilités bien connues dans l’industrie. Pour une sécurité maximale, tous les clients Auth0 doivent passer à TLS 1.2 ou à une version ultérieure. Les détails précis et les étapes requises varient selon votre application.
Dépréciation : janvier 2018Fin de vie : janvier 2021Auth0 a déprécié l’utilisation de la bibliothèque auth0-analytics.js, qui ajoute à Lock l’intégration à Facebook et à Google Analytics. Elle écoute les événements dans Lock et les transmet à la bibliothèque Auth0-tag-manager.js. Elle peut encore fonctionner dans certains anciens scénarios. 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’analytique tierces comme Facebook, X et Google.
Dépréciation des métadonnées des identifiants d’appareil sans user_id
Déprécié : 31 août 2020Fin de vie : 17 décembre 2020Auth0 exige désormais que vous fournissiez le user_id lorsque vous utilisez le point de terminaison GET /api/v2/device-credentials. Si votre requête ne contient pas de user_id, elle renverra un code d’état 400. Vérifiez la depnote dans les journaux de votre tenant pour voir si vous êtes touché par cette dépréciation.Auth0 a identifié les tenants touchés par cette dépréciation et a communiqué avec leurs administrateurs. Si votre tenant envoie actuellement des requêtes sans user_id, vous devriez apporter cette modification dès que possible.
Dépréciation de la vérification des courriels pour Azure AD/ADFS
Déprécié :
Public Cloud : 18 novembre 2020
Private Cloud : 1 décembre 2020
Fin de vie :
Public Cloud : 18 mai 2021
Private Cloud : version de juin de Private Cloud (v2106)
Auparavant, Auth0 définissait le champ email_verified sur true dans les connexions Azure AD et ADFS. Si vous utilisiez des connexions Azure AD/ADFS avant cette date de dépréciation, vous avez un paramètre de tenant qui remplace le paramètre de connexion pour la vérification des courriels et conserve le comportement précédent.Le 18 mai 2021 dans Public Cloud et avec la version de juin de Private Cloud (v2106), Auth0 commence à 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.
changements apportés à l’attribut sameSite des cookies
En vigueur : février 2020Google Chrome v80 modifie la façon dont il gère les cookies. À cette fin, Auth0 apportera les changements suivants à la façon dont il gère les cookies :
Les cookies sans attribut samesite seront définis sur lax
Les cookies avec sameSite=none doivent être sécurisés, sinon ils ne peuvent pas être enregistrés dans le cookie jar du navigateur
L’objectif de ces changements est d’améliorer la sécurité et d’aider à atténuer les attaques CSRF. Pour en savoir plus, consultez sameSite Cookie Attribute Changes.
Déprécié : 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éprécié et vous auriez dû agir avant le 30 juin 2019. Des notifications ont été envoyées aux clients devant terminer 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.
Dépréciation du point de terminaison Passwordless pour les applications confidentielles
Auth0 a abandonné l’utilisation du point de terminaison /passwordless/start pour les applications confidentielles lorsqu’Auth0 ne peut pas vérifier que la requête est effectuée au nom de l’application. Pour en savoir plus, consultez Migrer vers le point de terminaison Passwordless pour les applications confidentielles.Changements apportés à la protection contre le détournement de clic pour Pour prévenir le détournement de clic, lorsque 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 clic pour Universal Login.
Dépréciation : 08 juillet 2017Fin de vie : TBDDepuis le 08 juillet 2017, Auth0 a déprécié le point de terminaison /oauth/ro pour les connexions avec 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 offerte dans le Cloud privé jusqu’à la version mensuelle de novembre 2020, qui sera la première à ne plus inclure Management API v1. Vous pourriez devoir prendre des mesures avant cette date afin d’éviter toute interruption de service. Des notifications ont été envoyées aux clients qui doivent effectuer cette migration, et elles continueront de l’être.
Déprécié : 05 mars 2020Fin de vie : 31 mars 2020Facebook a annoncé que, le 31 mars 2020, les API héritées d’Instagram seraient désactivées et qu’aucune solution de rechange ne serait offerte pour permettre la connexion avec Instagram. Pour en savoir plus, consultez Dépréciation de la connexion Instagram.
Deprecated: 01 mars 2020End of life: 01 mars 2020Yahoo a modifié la façon de récupérer le profil utilisateur ainsi que les renseignements qu’il contient. Pour en savoir plus, consultez Yahoo API Changes.
dépréciation : 11 avril 2019Fin de vie : 11 avril 2019À compter du 11 avril 2019, Google a abandonné Google Cloud Messaging (GCM) et l’a remplacé par Firebase Cloud Messaging (FCM). Pour en savoir plus, consultez Google to Firebase Cloud Messaging Migration.
Dépréciation : 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 Dépréciation du champ Social Context de Facebook.
Dépréciation : 01 août 2018Fin de vie : Graph API v3 publiée le 08 janvier 2019À compter du 01 août 2018, Facebook a modifié les autorisations et les champs pouvant être demandés dans Facebook Graph API. Auth0 a mis à jour les connexions Facebook pour tenir compte de ces changements et a modifié l’interface de connexion Facebook afin d’en améliorer la clarté. Consultez Facebook Login Changelog: Recent Changes to Facebook Login pour tous les détails et les dates importantes. Pour en savoir plus, consultez Changements apportés à Facebook Graph API.
Nous améliorons continuellement la sécurité de notre service. Dans le cadre de ces efforts, nous avons déprécié l’API Legacy Lock, qui 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 faire l’objet de requêtes directes à partir des 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 complètement la vulnérabilité CSRF divulguée en avril 2018. Elle met également fin à la période de grâce liée au retrait progressif, 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 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. Vérifiez les erreurs de dépréciation pour identifier la ou les sources de toute erreur liée aux dépréciations dans les journaux de votre tenant.
Si vous utilisez actuellement Lock v8, v9 ou v10, ou Auth0.js v6, v7 ou v8, pour implémenter la connexion dans votre application, vous êtes concerné par ces changements. De plus, vous êtes concerné 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 de la bibliothèque qu’elles utilisent dans la page de connexion.Toutefois, 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 les SDK qui ne sont pas explicitement nommés ici ne sont pas touchés par cette migration.
Professional (anciennement Developer Pro) : 20 août 2019
Enterprise : 04 novembre 2019
Afin d’offrir à ses clients la solution la plus fiable et la plus évolutive possible, Auth0 a déprécié 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 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 à mettre sur 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 mettez des adresses IP sur liste d’autorisation, vous devrez ajouter ces nouvelles adresses aux règles de votre pare-feu.
Si vous utilisez une connexion de base de données personnalisée, une règle et/ou un fournisseur de courriel personnalisé qui se connecte à votre environnement, et que vous avez mis en place des restrictions de pare-feu pour des plages d’adresses IP, ce changement vous concerne. 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
Nouvelles adresses IP à ajouter à la liste d’autorisation en Europe
Depuis le 30 septembre 2017, Auth0 a mis à jour ses environnements infonuagiques, et le trafic provenant d’Europe provient désormais de nouvelles adresses IP. Si vous utilisez une liste d’autorisation d’adresses IP, vous devrez ajouter ces nouvelles adresses aux règles de votre pare-feu.
Si vous utilisez une connexion de base de données personnalisée, une règle ou un fournisseur de courriel personnalisé qui se connecte à 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 à traverser 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 maintenant Amazon CloudFront. Nous avons déjà apporté ce changement dans l’environnement américain et sommes maintenant prêts à le faire 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 aucune interruption ni modifier le comportement de vos applications; vous n’avez donc rien à faire. Cet avis est fourni à titre informatif seulement.
Migration des Rules pour les échanges Password et refresh token
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 (l’échange de mot de passe) et lors de l’échange de refresh token.
Vous utilisez cette fonctionnalité si vous envoyez une requête au 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 le Dashboard. Afin d’assurer une transition en douceur, nous avons désactivé l’exécution des Rules pour ces échanges précis dans votre tenant. 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 Refresh Token
Si vous souhaitez activer le nouveau comportement sur ce tenant à des fins de test avant la date limite d’activation obligatoire, connectez-vous au Dashboard et activez la bascule Exécuter les Rules sur les échanges Password et Refresh Token dans Paramètres du tenant > Avancé.
Le 1er mars 2017, dans le cadre des efforts d’Auth0 pour améliorer la sécurité et la conformité aux normes, nous avons cessé de prendre en charge la liaison de comptes dans le cadre du callback d’autorisation (c’est-à-dire l’acceptation d’un access token dans la requête authorize).
Si vous avez reçu une notification par courriel à ce sujet, vous êtes concerné par ce changement. Pendant que vous mettez à jour vos applications pour utiliser la Management API afin de lier des comptes, vous pouvez vérifier si c’est encore le cas en consultant les journaux de votre tenant pour y repérer des avertissements. Ces entrées seront consignées si vous envoyez un jeton d’accès dans vos requêtes authorize.
Depuis le 20 février 2017, Auth0 s’est étendu à de nouvelles régions aux États-Unis, et le trafic provenant de ces régions utilisera de nouvelles adresses IP. Si vous avez mis des adresses IP sur la liste d’autorisation, vous devrez ajouter ces nouvelles adresses aux règles de votre pare-feu.
Si vous utilisez une connexion de base de données personnalisée, une règle et/ou un fournisseur de courriels 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 de réinitialisation du mot de passe vulnérable
Avant le 1er février 2017, le processus de réinitialisation du mot de passe d’Auth0 permettait à l’utilisateur de saisir son courriel et un nouveau mot de passe. Cela entraînait l’envoi d’un courriel de confirmation lui demandant de confirmer qu’il avait bien demandé une réinitialisation du mot de passe.
Le problème, c’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.Lock 9 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 le nouveau flux de réinitialisation du mot de passe. Nous 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 encourage fortement à faire passer immédiatement toute application utilisant le flux actuel vers le nouveau flux de réinitialisation et à 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 à partir d’une Auth0 rule, Auth0 génère et envoie un state parameter en HTTP, puis vérifie la présence d’un state parameter valide lorsque le flow revient au point de terminaison /continue. Le site vers lequel la redirection est effectuée doit récupérer la valeur du state parameter et la renvoyer en l’ajoutant comme paramètre lors du retour au 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 ni ne le renvoyez au point de terminaison /continue.
Changement 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 ressemblait au point de terminaison permettant de supprimer un seul utilisateur : DELETE /api/v2/users. Afin d’éviter les requêtes accidentelles vers le point de terminaison de suppression de tous les utilisateurs, l’URL a été modifiée pour DELETE /api/v2/allusers. Cela devrait garantir que seuls des appels intentionnels à ce point de terminaison soient effectués.
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 est de changer l’URL, comme expliqué ci-dessus.
Changements apportés à la personnalisation des modèles d’envoi de courriels
Depuis le 29 août 2016, le fournisseur de courriel intégré d’Auth0 n’est plus pris en charge dans un environnement de production. Les courriels envoyés au moyen du fournisseur d’Auth0 ne pourront plus être personnalisés. Vous devrez utiliser le modèle tel quel 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 basé sur SMTP) avant de faire passer vos applications en production. Si vous utilisez déjà un fournisseur de courriel personnalisé, aucune action n’est nécessaire.
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 les API d’authentification Auth0 a été modifié : le jeton d’accès du fournisseur d’identité a été retiré du tableau identities inclus dans le 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} avec un jeton d’API généré avec la portée read:user_idp_tokens. Vous aurez toujours accès au jeton d’accès du fournisseur d’identité dans l’argument user des règles Auth0.
Vous n’êtes concerné par ce changement que si vous utilisez le jeton d’accès du fournisseur d’identité (identities[0].access_token dans le profil utilisateur) en dehors des Rules pour effectuer des requêtes vers d’autres services du fournisseur d’identité (comme Facebook Graph API, Google APIs, etc.). Si votre tenant a été créé après ce changement, la mise à jour sera effectuée automatiquement.
À compter du 1er juin 2016, lors d’un 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 du jeton d’identité en cours de validation. Si ces valeurs ne correspondent pas, la réponse sera HTTP 400 - Bad Request.
Si vous interrogez directement le point de terminaison Tokeninfo, assurez-vous que la valeur de l’attribut iss du jeton d’identité en cours de validation correspond à l’espace de noms de votre tenant Auth0 : https://{yourDomain}/. Vous pouvez utiliser jwt.io pour décoder le token et confirmer la valeur de l’attribut iss.
Changements à l’adresse d’expéditeur des courriels
Le 27 avril 2016, le fournisseur de courriels 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 courriels personnalisés sont désormais gratuits. Pour personnaliser l’adresse d’expéditeur, vous pouvez passer à 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 courriels 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 d’applications PATCH et POST.Afin de mieux respecter 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 les 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.
Authentifier
Gérer les utilisateurs
Personnaliser
Plateforme