> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Liste des mises à jour d’Auth0 qui ont déjà été activées pour tous les clients.

# Anciennes migrations

Voici les migrations déjà activées pour tous les clients. Si vous avez des questions, soumettez une demande dans notre [Support Center](https://support.auth0.com/center/s/).

<div id="protected-properties-in-non-custom-social-connections">
  ## Propriétés protégées dans les connexions sociales non personnalisées
</div>

**Déprécié** : 30 juillet 2024

**Fin de vie** : 31 janvier 2025

Les 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.

<div id="unwarranted-session-removal-after-management-api-user-updates">
  ## Suppression injustifiée de sessions après des mises à jour d’utilisateurs par la Management API
</div>

**Déprécié** : 11 février 2025

**Fin de vie** : 19 août 2025

Le point de terminaison [Mettre à jour un utilisateur](https://auth0.com/docs/api/management/v2/users/patch-users-by-id) (`PATCH /api/v2/users/{id}`) de la <Tooltip tip="Management API : un produit qui permet aux clients d’effectuer des tâches administratives." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Management+API">Management API</Tooltip> 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`.

<div id="mandatory-use-of-sni-for-https-requests">
  ## Utilisation obligatoire du SNI pour les requêtes HTTPS
</div>

**Déprécié** : 29 octobre 2024

**Fin de vie** : 29 avril 2025

Le service Auth0 exigera l’utilisation de [Server Name Indication](https://en.wikipedia.org/wiki/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](https://support.auth0.com/center/s/article/End-of-Life-Rollout-for-Mandatory-Use-of-SNI-for-HTTPS-Requests).

<div id="always-use-https-for-communication-with-auth0">
  ## Utilisez toujours HTTPS pour communiquer avec Auth0
</div>

**Déprécié** : 4 septembre 2024

**Fin 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.

<div id="management-api-transition-updating-roles-assignment-to-require-create-scope">
  ## Transition de la Management API : mise à jour de l’attribution des rôles pour exiger le scope Create
</div>

**Deprecated** : 7 mars 2024

**End of life** : 10 septembre 2024

Les 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`.

<div id="update-applications-that-use-cross-origin-authentication">
  ## Mettre à jour les applications qui utilisent l’authentification inter-origines
</div>

**Déprécié** : 25 avril 2024

**Fin de vie** : 10 octobre 2024

Les 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](https://auth0.com/docs/api/management/v2/clients/get-clients), [Récupérer le client par ID](https://auth0.com/docs/api/management/v2/clients/get-clients-by-id)) devront être modifiées pour utiliser `cross_origin_authentication`.

<div id="remove-subscription-tickets-access-for-tenant-admins">
  ## Retirer l’accès aux Subscription Tickets pour les administrateurs de tenant
</div>

**Déprécié** : 5 juin 2024

**Fin de vie** : 5 août 2024

L’accès aux [Subscription Tickets](/docs/fr-ca/troubleshoot/customer-support/open-and-manage-support-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.

<div id="password-reset-and-email-verification-links-in-tenant-logs-deprecation">
  ## Dépréciation des liens de réinitialisation du mot de passe et de vérification du courriel dans les journaux du tenant
</div>

**Déprécié** : 7 décembre 2023

**Fin de vie** : 5 février 2024

Les 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’<Tooltip tip="Management API : produit permettant aux clients d’effectuer des tâches administratives." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Management+API">Management API</Tooltip>.

<div id="reducing-maximum-expiration-time-for-login-transactions">
  ## Réduction de la durée de vie maximale des transactions de connexion
</div>

**Déprécié** : 5 septembre 2023 (Public Cloud), 21 novembre 2023 (Private Cloud)

**Fin de vie** : 21 février 2024

Avec 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.

<div id="unregistered-scopes-in-refresh-tokens-deprecation">
  ## Dépréciation des portées non enregistrées dans les jetons d’actualisation
</div>

**Déprécié** : 12 juillet 2023

**Fin de vie** : 17 janvier 2024

Nous améliorons l’évaluation des portées lors de l’échange de <Tooltip tip="Jeton d’actualisation : jeton utilisé pour obtenir un jeton d’accès renouvelé sans obliger les utilisateurs à se connecter de nouveau." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=refresh+token">jeton d’actualisation</Tooltip> 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](/docs/fr-ca/customize/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.

<div id="auth0-cordova-angular-auth0-and-express-oauth2-bearer-repo-deprecations">
  ## Dépréciation des dépôts auth0-cordova, angular-auth0 et express-oauth2-bearer
</div>

**Déprécié** : 27 avril 2023

**Fin 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 :

* [express-oauth2-bearer](https://github.com/auth0/express-oauth2-bearer) | [guide de migration](https://github.com/auth0/express-oauth2-bearer/blob/master/MIGRATION_GUIDE.md)
* [angular-auth0](https://github.com/auth0/angular-auth0) | [guide de migration](https://github.com/auth0/angular-auth0/blob/master/MIGRATION_GUIDE.md)
* [auth0-cordova](https://github.com/auth0/auth0-cordova) | [guide de migration](https://github.com/auth0/auth0-cordova/blob/master/MIGRATION_GUIDE.md)

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.

<div id="actions-migration-from-nodejs-16-to-nodejs-18">
  ## Migration des Actions de Node.js 16 vers Node.js 18
</div>

**Date cible de migration** : 11 sept. 2023

Dans 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.

<div id="support-for-edgejs-in-extensibility-features">
  ## Prise en charge d’edge.js dans les fonctionnalités d’extensibilité
</div>

**Déprécié :** 21 décembre 2022

**Fin de vie :** 21 juin 2023

Après le 21 juin 2023, Auth0 ne prendra plus en charge l’exécution de .NET et de C# à partir de Node.js dans les fonctionnalités d’extensibilité. Auth0 prenait 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](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/migrate-from-edge-js-extensibility-features).

<div id="support-for-oracledb-in-extensibility-features">
  ## Prise en charge de oracledb dans les fonctionnalités d’extensibilité
</div>

**Déprécié :** 21 décembre 2022

**Fin de vie :** 21 juin 2023

Auth0 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](https://www.npmjs.com/package/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](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/migrate-from-oracledb-extensibility-features).

<div id="auth0-claims-provider-for-sharepoint-2010-2013">
  ## Fournisseur de revendications Auth0 pour SharePoint 2010 / 2013
</div>

**Déprécié :** 31 janvier 2023

**Fin de vie :** 31 juillet 2023

Auth0 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.

<div id="checkpoint-pagination-on-get-role-users-endpoint">
  ## Pagination par checkpoint pour le point de terminaison Get Role Users
</div>

**Déprécié :** 9 novembre 2022

**Fin de vie :** 9 mai 2023

Pour 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](https://auth0.com/docs/api/management/v2/roles/get-role-user).

<div id="legacy-custom-claims">
  ## Revendications personnalisées héritées
</div>

**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 <Tooltip tip="JSON Web Token (JWT) : format de jeton ID standard (et souvent format de jeton d’accès) utilisé pour représenter des revendications de façon sécurisée entre deux parties." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=JWT">JWT</Tooltip> à 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 <Tooltip tip="Jeton ID : justificatif destiné au client lui-même, plutôt qu’à l’accès à une ressource." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=ID+tokens">jetons ID</Tooltip> au moyen du code d’extensibilité ([Rules](/docs/fr-ca/customize/rules) / [Hooks](/docs/fr-ca/customize/hooks) / [Actions](/docs/fr-ca/customize/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 <Tooltip tip="Jeton d’accès : justificatif d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisé pour accéder à une API." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=access+tokens">jetons d’accès</Tooltip> ; 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](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/custom-claims-migration).

Si votre tenant exécute du code d’extensibilité ([Rules](/docs/fr-ca/customize/rules) / [Hooks](/docs/fr-ca/customize/hooks) / [Actions](/docs/fr-ca/customize/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 <Tooltip tip="OpenID : norme ouverte d’authentification permettant aux applications de vérifier l’identité des utilisateurs sans recueillir ni stocker les renseignements de connexion." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OPENID">OPENID</Tooltip> 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 <Tooltip tip="Audience : identifiant unique de l’audience d’un jeton émis. Nommée aud dans un jeton, sa valeur contient l’ID d’une application (Client ID) pour un jeton ID ou d’une API (API Identifier) pour un jeton d’accès." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=audience">audience</Tooltip> 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 \$.

Pour en savoir plus sur les revendications personnalisées, consultez [Créer des revendications personnalisées](/docs/fr-ca/secure/tokens/json-web-tokens/create-custom-claims).

<div id="legacy-private-cloud-platform">
  ## Ancienne plateforme Private Cloud
</div>

**Déprécié :** 13 juin 2022

**Fin de vie :** 31 janvier 2023

Nous 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.

<div id="log-extensions">
  ## Extensions de logs
</div>

**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](https://marketplace.auth0.com/). À 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](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/migrate-from-log-extensions).

<div id="tenant-hostname-validation">
  ## Validation du nom d’hôte du tenant
</div>

**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)

Pour en savoir plus, consultez [Tenant Hostname Validation Migration](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/tenant-hostname-migration).

<div id="nodejs-16-migration">
  ## Migration vers Node.js 16
</div>

**Fin de vie** : 30 avril 2022

Le 30 avr. 2022, [Node.js v12 est arrivé à la fin de sa période de soutien à long terme (LTS)](https://github.com/nodejs/Release#release-schedule), 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](#breaking-changes-rules-only)), 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.

<div id="opaque-access-token-and-authorization-code-fixed-length">
  ## Longueur fixe des jetons d’accès opaques et des codes d’autorisation
</div>

**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](https://datatracker.ietf.org/doc/html/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.

<div id="nodejs-v8-extensibility-runtime-end-of-life">
  ## Fin de vie du runtime d’extensibilité Node.js v8
</div>

**Déprécié** : 15 avril 2020

**Fin 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)](https://github.com/nodejs/Release#release-schedule). 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](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/migrate-to-nodejs-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](/docs/fr-ca/customize/actions/migrate/migrate-from-rules-to-actions).

<div id="legacy-network-edge-deprecation">
  ## Dépréciation de l’ancienne périphérie réseau
</div>

**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 <Tooltip tip="Domaine personnalisé : domaine tiers avec un nom spécialisé ou personnalisé." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=custom+domains">domaines personnalisés</Tooltip> sont automatiquement créés sur la nouvelle périphérie réseau.

<div id="unpaginated-management-api-v2-request-deprecation">
  ## Dépréciation des requêtes non paginées vers Management API v2
</div>

**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.

* [`GET /api/v2/clients`](https://auth0.com/docs/api/management/v2#!/Clients/get_clients)
* [`GET /api/v2/client-grants`](https://auth0.com/docs/api/management/v2#!/Clients/client_grants)
* [`GET /api/v2/grants`](https://auth0.com/docs/api/management/v2#!/Clients/grants)
* [`GET /api/v2/connections`](https://auth0.com/docs/api/management/v2#!/Clients/connections)
* [`GET /api/v2/device-crecentials`](https://auth0.com/docs/api/management/v2#!/Clients/device_credentials)(lorsque le paramètre de requête `type` est utilisé)
* [`GET /api/v2/resource-servers`](https://auth0.com/docs/api/management/v2#!/Clients/resource_servers)
* [`GET /api/v2/rules`](https://auth0.com/docs/api/management/v2#!/Clients/rules)

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](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/migrate-to-paginated-queries).

<div id="private-cloud-custom-domain-deprecation">
  ## Dépréciation de Custom Domain dans Private Cloud
</div>

**Déprécié** : 17 juin 2021

**Fin de vie** : 20 décembre 2021

Afin 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.

<div id="logout-redirect-validation">
  ## Validation de la redirection à la déconnexion
</div>

**Déprécié** : 25 mai 2021

**Fin de vie** : 01 décembre 2021

Le 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 <Tooltip tip="Fournisseur d’identité (IdP) : service qui stocke et gère les identités numériques." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Identity+Providers">fournisseurs d’identité</Tooltip> à `/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](/docs/fr-ca/troubleshoot/product-lifecycle/deprecations-and-migrations/logout-return-to).

<div id="application-admin-dashboard-role-deprecation">
  ## Dépréciation du rôle Dashboard Application Admin
</div>

**Déprécié** : 01 février 2021

**Fin 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

À compter du 01 février 2021, Auth0 affichera une bascule de migration pour vous aider à vous préparer à ce changement. Pour en savoir plus, consultez [Migrer vers la gestion des nouveaux rôles du Dashboard](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/migrate-tenant-member-roles).

<div id="legacy-tls-deprecation">
  ## Dépréciation des anciennes versions de TLS
</div>

**Déprécié** : 19 janvier 2021

**Fin 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.

<div id="auth0-analyticsjs-deprecation">
  ## Dépréciation d’Auth0-analytics.js
</div>

**Dépréciation** : janvier 2018

**Fin de vie** : janvier 2021

Auth0 a déprécié l’utilisation de la [bibliothèque auth0-analytics.js](https://github.com/auth0/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](https://github.com/auth0/auth0-tag-manager) afin de gérer les requêtes proxy vers des bibliothèques d’analytique tierces comme Facebook, X et Google.

<div id="device-credential-metadata-without-user_id-deprecation">
  ## Dépréciation des métadonnées des identifiants d’appareil sans `user_id`
</div>

**Déprécié** : 31 août 2020

**Fin de vie** : 17 décembre 2020

Auth0 exige désormais que vous fournissiez le `user_id` lorsque vous utilisez le [point de terminaison GET /api/v2/device-credentials](https://auth0.com/docs/api/management/v2/#!/Device_Credentials/get_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.

<div id="azure-adadfs-email-verification-deprecation">
  ## Dépréciation de la vérification des courriels pour Azure AD/ADFS
</div>

**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](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/azuread-adfs-email-verification).

<div id="samesite-cookie-attribute-changes">
  ## changements apportés à l’attribut sameSite des cookies
</div>

**En vigueur** : février 2020

Google 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](/docs/fr-ca/manage-users/cookies/samesite-cookie-attribute-changes).

<div id="user-search-v2-deprecation">
  ## Dépréciation de User Search v2
</div>

**Déprécié** : 10 novembre 2018

**Fin 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.

<div id="passwordless-endpoint-from-confidential-applications-deprecation">
  ## Dépréciation du point de terminaison Passwordless pour les applications confidentielles
</div>

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](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/migrate-to-passwordless).Changements apportés à la protection contre le détournement de clic pour <Tooltip tip="Universal Login : votre application redirige vers Universal Login, hébergé sur le serveur d’autorisation d’Auth0, pour vérifier l’identité d’un utilisateur." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Universal+Login">Universal Login</Tooltip>

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](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/clickjacking-protection-for-universal-login).

<div id="management-api-endpoints-using-id-token-credentials-deprecation">
  ## Dépréciation des points de terminaison de la Management API qui utilisent des jetons d’identification comme identifiants
</div>

**Dépréciation** : 31 mars 2018

**Fin de vie** : À déterminer

Auth0 abandonne progressivement l’utilisation des jetons d’identification comme identifiants pour effectuer des requêtes vers certains points de terminaison des utilisateurs et des appareils, au profit des jetons d’accès. Pour en savoir plus, consultez [Migrer vers les points de terminaison de la Management API avec des jetons d’accès](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/migrate-to-calling-api-with-access-tokens) et [Migrer vers l’association de comptes d’utilisateur à l’aide de jetons d’accès](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/link-user-accounts-with-access-tokens-migration).

<div id="resource-owner-password-oauthro-deprecation">
  ## Dépréciation de Resource Owner Password /oauth/ro
</div>

**Dépréciation** : 08 juillet 2017

**Fin de vie** : TBD

Depuis le 08 juillet 2017, Auth0 a déprécié le point de terminaison `/oauth/ro` pour les connexions avec mot de passe et <Tooltip tip="Sans mot de passe : forme d’authentification qui ne repose pas sur un mot de passe comme premier facteur." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=passwordless">sans mot de passe</Tooltip>. 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](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/migration-oauthro-oauthtoken).

<div id="management-api-v1-deprecation">
  ## Dépréciation de Management API v1
</div>

**Dépréciation** : octobre 2016

**Fin de vie** :

* Cloud public : 13 juillet 2020
* Cloud privé : version mensuelle de novembre 2020

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.

<div id="instagram-connection-deprecation">
  ## Dépréciation de la connexion Instagram
</div>

**Déprécié** : 05 mars 2020

**Fin de vie** : 31 mars 2020

Facebook 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](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/instagram-connection-deprecation).

<div id="yahoo-api-changes">
  ## Modifications de l’API Yahoo
</div>

**Deprecated**: 01 mars 2020

**End of life**: 01 mars 2020

Yahoo 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](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/yahoo-api-changes).

<div id="google-cloud-messaging-deprecation">
  ## Abandon de Google Cloud Messaging
</div>

**dépréciation** : 11 avril 2019

**Fin de vie** : 11 avril 2019

À compter du 11 avril 2019, [Google a abandonné](https://firebase.googleblog.com/2018/04/time-to-upgrade-from-gcm-to-fcm.html) Google Cloud Messaging (GCM) et l’a remplacé par Firebase Cloud Messaging (FCM). Pour en savoir plus, consultez [Google to Firebase Cloud Messaging Migration](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/google-firebase-migration).

<div id="facebook-social-context-field-deprecation">
  ## Dépréciation du champ Social Context de Facebook
</div>

**Dépréciation** : 30 avril 2019

**Fin de vie** : 30 juillet 2019

Le 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](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/facebook-social-context-field-deprecation).

<div id="facebook-graph-api-changes">
  ## Changements apportés à Facebook Graph API
</div>

**Dépréciation** : 01 août 2018

**Fin 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](https://developers.facebook.com/docs/facebook-login/changelog#2018-07-02) pour tous les détails et les dates importantes. Pour en savoir plus, consultez [Changements apportés à Facebook Graph API](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/facebook-graph-api-changes).

<div id="lock-v11-and-auth0js-v9">
  ## Lock v11 et Auth0.js v9
</div>

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](https://auth0.com/blog/managing-and-mitigating-security-vulnerabilities-at-auth0/). 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.

### Fonctionnalités touchées

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.

<div id="tenant-log-search-v2-deprecation">
  ## Dépréciation de Tenant Log Search v2
</div>

**Dépréciation** : 21 mai 2019

**Fin de vie** :

* Free : 09 juillet 2019
* Essential (anciennement Developer) : 20 août 2019
* 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](/docs/fr-ca/troubleshoot/product-lifecycle/past-migrations/migrate-to-tenant-log-search-v3).

<div id="new-ip-addresses-for-allowlisting-in-australia">
  ## Nouvelles adresses IP à mettre sur la liste d’autorisation en Australie
</div>

À 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.

### Fonctionnalités touchées

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`

<div id="new-ip-addresses-for-allowlisting-in-europe">
  ## Nouvelles adresses IP à ajouter à la liste d’autorisation en Europe
</div>

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.

<div id="features-affected">
  ### Fonctionnalités concernées
</div>

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`

<div id="cdn-provider-migration-in-the-europe-and-australia-environments">
  ## Migration du fournisseur de CDN dans les environnements d’Europe et d’Australie
</div>

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.

<div id="features-affected">
  ### Fonctionnalités concernées
</div>

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.

<div id="password-and-refresh-token-exchange-rules-migration">
  ## Migration des Rules pour les échanges Password et refresh token
</div>

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 <Tooltip tip="OAuth 2.0 : cadre d’autorisation qui définit les protocoles et les flux de travail d’autorisation." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> <Tooltip tip="OAuth 2.0 : cadre d’autorisation qui définit les protocoles et les flux de travail d’autorisation." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Resource+Owner">Resource Owner</Tooltip> Password Grant (l’échange de mot de passe) et lors de l’échange de refresh token.

<div id="features-affected">
  ### Fonctionnalités concernées
</div>

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](https://manage.auth0.com/#) et activez la bascule **Exécuter les Rules sur les échanges Password et Refresh Token** dans [Paramètres du tenant > Avancé](https://manage.auth0.com/#/tenant/advanced).

<div id="account-linking-removal">
  ## Suppression de la liaison de comptes
</div>

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`).

<div id="features-affected">
  ### Fonctionnalités concernées
</div>

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.

<div id="allowlist-ip-address-ranges">
  ## Plages d’adresses IP de la liste d’autorisation
</div>

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.

<div id="features-affected">
  ### Fonctionnalités concernées
</div>

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`

<div id="vulnerable-password-flow">
  ## Processus de réinitialisation du mot de passe vulnérable
</div>

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.

### Fonctionnalités touchées

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.

<Warning>
  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.
</Warning>

<div id="state-parameter-required-on-redirect-from-rule">
  ## Paramètre state requis lors d’une redirection depuis une rule
</div>

À 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`.

<div id="features-affected">
  ### Fonctionnalités concernées
</div>

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.

<div id="delete-all-users-endpoint-change">
  ## Changement du point de terminaison de suppression de tous les utilisateurs
</div>

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.

<div id="features-affected">
  ### Fonctionnalités concernées
</div>

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.

<div id="email-delivery-template-customization-changes">
  ## Changements apportés à la personnalisation des modèles d’envoi de courriels
</div>

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](https://aws.amazon.com/ses/), [Mailchimp](https://mailchimp.com/features/transactional-email/), [SendGrid](https://sendgrid.com/en-us/pricing) 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.

<div id="identity-provider-access-tokens-removed-from-user-profile-and-id-token">
  ## Jetons d’accès du fournisseur d’identité supprimés du profil utilisateur et du jeton d’identité
</div>

À 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.

### Fonctionnalités touchées

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.

<div id="tokeninfo-endpoint-validation">
  ## Validation du point de terminaison Tokeninfo
</div>

À 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`.

### Fonctionnalités touchées

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](https://www.jwt.io/) pour décoder le token et confirmer la valeur de l’attribut `iss`.

<div id="email-delivery-from-address-changes">
  ## Changements à l’adresse d’expéditeur des courriels
</div>

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](https://aws.amazon.com/ses/), [Mailchimp](https://mailchimp.com/features/transactional-email/), [SendGrid](https://sendgrid.com/en-us/pricing)) ou à un autre fournisseur fondé sur SMTP. Si vous utilisez déjà un fournisseur de courriels personnalisé, rien ne changera.

<div id="patch-and-post-endpoints-no-longer-accept-secret_encoded-flag">
  ## Les points de terminaison PATCH et POST n’acceptent plus l’indicateur secret\_encoded
</div>

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.

<div id="features-affected">
  ### Fonctionnalités concernées
</div>

Ce changement vous concerne uniquement si vous interagissez directement avec ces points de terminaison.