Cycle de vie des produits

Découvrez le cycle de vie des produits Auth0, y compris les étapes de lancement, les dépréciations, la fin de vie, le processus de migration et les migrations actives.

Lorsque nous concevons des produits Auth0, nous nous engageons à :

• Offrir de la valeur aux clients tôt et souvent, en itérant selon leurs commentaires
• Chercher à bien comprendre nos clients et en tenir compte dans chacune de nos décisions
• Recueillir et analyser sans relâche les données, 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 explique 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 les changements courants et leur compatibilité afin de définir les attentes pour les intégrations. Les changements décrits ne sont ni exhaustifs ni complets; pour en savoir plus sur les changements avec rupture, consultez les rubriques ci-dessous.

À lire…	Pour en savoir plus…
Étapes de lancement des produits	Comment Auth0 classe, lance et retire des fonctionnalités de produit.
Processus de migration	Comment fonctionne le processus de dépréciation et de migration d’Auth0.
Dépréciations et migrations	Renseignements sur les dépréciations en cours et la façon de migrer vers de nouveaux comportements ou de nouvelles fonctionnalités.
Migrations passées	Migrations passées précédemment activées pour les clients.

​

API d’Auth0

Auth0 expose et maintient des API comme l’API d’authentification et la Management API, qui définissent chacune un contrat entre Auth0 et ses clients sur la base des spécifications d’API documentées et des artefacts associés. Auth0 suit des normes reconnues, notamment celles de l’IETF et d’OIDC; lorsqu’il n’existe pas de norme, des API propriétaires sont développées conformément aux pratiques exemplaires.

Des modifications apportées à ces API, qu’elles soient rétrocompatibles ou non, sont parfois nécessaires pour améliorer leur fonctionnalité, leur sécurité ou leur rendement.

​

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’oblige pas les clients à prendre des mesures immédiates ni à participer au processus de migration.

Voici des exemples de changements sans rupture :

• Chaînes opaques : Le format et la taille des chaînes opaques (p. ex. les jetons et les ID) peuvent changer. Les applications ne devraient pas supposer une taille ou un format fixes. La taille maximale des chaînes opaques ne dépassera pas 4 096 caractères.
• Taille des JWT : Conformément à la spécification OAuth (RFC6749), la taille des JWT n’est pas définie. Auth0 peut émettre des JWT de taille variable, et les applications ne devraient pas supposer une taille précise.
• Taille du code d’autorisation : Les applications 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 applications doivent ignorer les paramètres de réponse non reconnus, ce qui permet à Auth0 d’ajouter de nouvelles fonctionnalités sans affecter le fonctionnement actuel.
• Nouvelles ressources, nouveaux champs, en-têtes ou scopes : L’ajout de nouvelles ressources d’API, de nouveaux champs, de nouveaux en-têtes ou de nouveaux scopes n’aura pas d’incidence sur les applications existantes 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 relatives aux changements d’API dans les étapes du cycle de vie du produit.

​

Changements non rétrocompatibles

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 les aider à adapter l’implémentation de leur locataire.

Voici quelques exemples de changements incompatibles :

• Suppression d’une ressource d’API : Si une ressource d’API est supprimée ou renommée, les applications qui dépendent de cette ressource subiront un changement incompatible.
• Modifications de la structure d’URI : La modification de la structure d’un URI existant peut perturber les applications 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 incompatible pour les applications qui utilisent ces éléments.
• Modifications des valeurs par défaut : Les changements apportés à la valeur par défaut d’un champ peuvent avoir une incidence sur les intégrations existantes et constituer un changement incompatible.
• Modifications des réponses d’erreur et des codes d’état : Les modifications apportées aux formats des réponses d’erreur, aux codes d’erreur ou aux codes d’état peuvent briser le comportement existant des applications.
• Format JWT : Les changements au format JWT des jetons constituent des changements incompatibles
• Format JSON : Changer le type d’une valeur JSON constitue un changement incompatible.

Tout changement incompatible 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 ci-dessous :

• Annonce de la dépréciation : Auth0 annonce la dépréciation afin d’informer les clients d’un changement à venir.
• Fenêtre 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 fenêtre de migration prend fin, la fonctionnalité obsolète passe à l’étape de fin de vie et n’est plus disponible.

​

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 de s’y appuyer pour des systèmes de production.