Skip to main content
Lorsque nous concevons des produits Auth0, nous nous engageons à :
  • Offrir rapidement et régulièrement de la valeur aux clients, en itérant selon leurs commentaires
  • Chercher à comprendre en profondeur nos clients et à en tenir compte dans chaque décision
  • Recueillir et analyser les données sans relâche afin de prendre de meilleures décisions
  • Visualiser et concevoir les versions actuelles, idéalisées et futures de l’ensemble de notre produit lors de l’ajout de fonctionnalités
Ce document fournit des indications sur ce qui constitue des changements rétrocompatibles (sans rupture) et des changements non rétrocompatibles (avec rupture) dans la plateforme Auth0. La distinction entre ces types de changements aide les développeurs à anticiper les répercussions possibles sur leurs applications lorsqu’ils utilisent les services Auth0. Ce document présente des changements courants et leur compatibilité afin d’aider à définir les attentes en matière d’intégrations. Les changements décrits ne sont pas exhaustifs; pour en savoir plus sur les changements avec rupture, consultez les sujets ci-dessous.

​
API d’Auth0

Auth0 propose et maintient des API comme les API d’authentification et de gestion d’Auth0, qui définissent chacune un contrat entre Auth0 et ses clients selon les spécifications d’API documentées et les artéfacts qui s’y rattachent. Auth0 suit des normes reconnues d’organisations comme l’IETF et OIDC; lorsqu’il n’existe pas de normes, des API propriétaires sont développées en respectant les pratiques exemplaires. Des modifications à ces API, qu’elles soient rétrocompatibles ou incompatibles avec les versions antérieures, sont parfois nécessaires pour en améliorer les fonctionnalités, la sécurité ou les performances.

​
Changements rétrocompatibles, sans rupture

Un changement rétrocompatible ne perturbe pas l’interopérabilité entre la plateforme Auth0 et les applications clientes, et n’exige pas que les clients prennent des mesures immédiates ni qu’ils participent au processus de migration. Voici quelques exemples de changements sans rupture :
  • Chaînes opaques : Le format et la taille des chaînes opaques (p. ex. les jetons, les ID) peuvent changer. Les clients ne doivent pas présumer d’une taille ou d’un format fixe. La taille maximale des chaînes opaques ne dépassera pas 4096 caractères.
  • Taille des  : Selon la spécification (RFC6749), la taille des credentials JWT n’est pas définie. Auth0 peut émettre des JWT de taille variable, et les clients ne doivent pas présumer d’une taille précise.
  • Taille du code d’autorisation : Les clients doivent s’attendre à ce que les codes d’autorisation, conformément à la spécification OAuth, puissent varier en taille.
  • Paramètres de réponse non reconnus : Les clients doivent ignorer les paramètres de réponse non reconnus, ce qui permet à Auth0 d’ajouter de nouvelles fonctionnalités sans incidence sur la fonctionnalité actuelle.
  • Nouvelles ressources, nouveaux champs, en-têtes ou scopes : L’ajout de nouvelles ressources d’API, de nouveaux champs, en-têtes ou scopes n’aura pas d’incidence sur les clients existants qui ne reconnaissent pas ou n’utilisent pas ces éléments.
Pour une explication plus détaillée des changements rétrocompatibles, consultez les directives d’Auth0 sur les modifications d’API dans les étapes du cycle de vie du produit.

​
Changements non rétrocompatibles et avec rupture

Un changement non rétrocompatible peut entraîner des défaillances lorsqu’il modifie l’interopérabilité entre la plateforme Auth0 et les applications des clients. Lorsqu’un tel changement est nécessaire, il suit le processus de dépréciation et de migration afin d’aviser les clients et de leur offrir le soutien nécessaire pour adapter la mise en œuvre de leur tenant. Voici quelques exemples de changements avec rupture :
  • Suppression d’une ressource d’API : si une ressource d’API est supprimée ou renommée, les clients qui s’y fient seront touchés par un changement avec rupture.
  • Modifications de la structure d’URI : modifier la structure d’un URI existant peut perturber les clients qui en dépendent.
  • Suppression d’une méthode, d’un paramètre ou d’un champ : si une méthode, un paramètre ou un champ est supprimé ou renommé, cela entraînera un changement avec rupture pour les clients qui utilisent ces éléments.
  • Modifications de la valeur par défaut : des changements à la valeur par défaut d’un champ peuvent avoir une incidence sur les intégrations existantes et constituer un changement avec rupture.
  • Modifications des réponses d’erreur et des codes d’état : des modifications aux formats de réponse d’erreur, aux codes d’erreur ou aux codes d’état peuvent rendre incompatible le comportement actuel des clients.
  • Format JWT : les changements au format JWT des jetons constituent des changements avec rupture
  • Format JSON : changer le type d’une valeur JSON constitue un changement avec rupture.
Tout changement avec rupture déclenche le processus de dépréciation, dans le cadre duquel les clients sont avisés et disposent d’au moins six mois pour migrer vers le nouveau comportement. Pour en savoir plus, consultez le processus de dépréciation et de fin de vie.

​
L’engagement d’Auth0

Auth0 réduit au minimum les perturbations causées par des changements non rétrocompatibles en suivant le processus suivant :
  • Annonce de dépréciation : Auth0 annonce la dépréciation afin d’aviser les clients d’un changement à venir.
  • Période de migration : Les clients disposent d’une période minimale de six mois pour migrer vers la fonctionnalité mise à jour; des directives sont fournies dans notre processus de migration.
  • Fin de vie : Lorsque la période de migration prend fin, la fonctionnalité dépréciée passe à l’étape de fin de vie et n’est plus offerte.

​
API non documentées

Les API Auth0 non documentées sont considérées comme privées et peuvent être modifiées sans préavis. Ces API ne sont pas couvertes par le processus de dépréciation, et les clients devraient éviter d’en dépendre dans des systèmes de production.