Cycle de vie des produits

Lorsque nous créons les produits Auth0, nous souhaitons :

• Offrir de la valeur à nos clients précocément et régulièrement, par itération basée sur leur rétroaction;

• Chercher à bien comprendre nos clients et les considérer dans chaque décision;

• Acquérir et analyser de manière constante les données, afin de pouvoir prendre des décisions éclairées;

• Visualiser et concevoir des versions actuelles, idéalisées et futures de notre offre produits lorsque nous ajoutons des fonctionnalités.

Ce document fournit des conseils sur les changements rétrocompatibles (sans rupture) et rétroincompatibles (avec rupture) dans la plateforme Auth0. La distinction entre ces changements aide les développeurs à anticiper les répercussions potentielles sur leurs applications lors de la consommation des services Auth0.

Ce document décrit les changements courants et leur compatibilité pour aider à établir des attentes en matière d’intégrations. Les changements décrits ne sont ni exhaustifs ni complets; consultez les rubriques ci-dessous pour plus de détails sur les changements avec rupture.

Auth0 expose et maintient des API telles que Authentication API et Management API, chacune d’entre elles définissant un contrat entre Auth0 et sa clientèle sur la base des spécifications documentées de l’API et des artefacts qui lui sont associés. Auth0 suit les normes reconnues par des organismes tels que l’IETF et l’OIDC. Lorsque des normes n’existent pas, des API exclusives sont développées tout en respectant les meilleures pratiques.

Des modifications de ces API, qu’elles soient rétrocompatibles ou non-rétroincompatibles, sont nécessaires de temps à autre pour améliorer leur fonctionnalité, leur sécurité ou leurs performances.

Un changement rétrocompatible ne perturbe pas l’interopérabilité entre la plateforme Auth0 et les applications du client et n’exige pas que les clients prennent des mesures immédiates ou participent 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, les identifiants) peuvent changer. Les clients ne doivent pas supposer une taille ou un format fixe. La taille maximale pour les chaînes opaques ne dépasse pas 4096 caractères.

• Taille du JWT : Selon la spécification OAuth (RFC6749), la taille des identifiants JWT n’est pas définie. Auth0 peut émettre des JWT de taille variable, et les clients ne doivent pas supposer une taille particulière.

• Taille du code d’autorisation : Les clients doivent s’attendre à ce que les codes d’autorisation, selon 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, permettant à Auth0 d’ajouter de nouvelles fonctionnalités sans affecter la fonctionnalité actuelle.

• Nouvelles ressources, champs, en-têtes ou permissions : L’ajout de nouvelles ressources, champs, en-têtes ou permissions API n’aura pas d’incidence sur les clients existants qui ne reconnaissent pas ces éléments ni ne les utilisent.

Pour une explication plus détaillée des changements rétrocompatibles, reportez-vous aux directives de modification d’API d’Auth0 dans les étapes du cycle de vie du produit.

Une modification non rétrocompatible avec les versions précédentes peut provoquer des pannes lorsqu’elle altère l’interopérabilité entre la plateforme Auth0 et les applications clients. Lorsqu’un tel changement est nécessaire, il suit le processus de dépréciation et de migration pour fournir un avis et du soutien aux clients afin qu’ils puissent ajuster leurs mises en œuvre locataires.

Voici des exemples de changements avec rupture :

• Suppression de ressources API : Si une ressource API est supprimée ou renommée, les clients qui comptent sur elle subiront un changement avec rupture.

• Changements de structure de l’URI : Modifier la structure d’un URI existant peut perturber les clients qui en dépendent.

• Méthode, paramètre ou suppression de champ : Si une méthode, un paramètre ou un champ est supprimé ou renommé, cela entraînera un changement avec rupture chez les clients qui l’utilisent.

• Changements de valeur 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 avec rupture.

• Changements de la réponse aux erreurs et du code d’état : Modifier les formats de réponse d’erreur, les codes d’erreur ou les codes d’état peut perturber le comportement du client.

• Format JWT : Les changements au format JWT des jetons correspondent à des changements avec rupture.

• Format JSON : Modifier le type d’une valeur JSON correspond à un changement avec rupture.

Tout changement avec rupture déclenche le processus de dépréciation. Les clients en sont informés et ont au moins six mois pour migrer vers le nouveau comportement. Pour plus de détails, reportez-vous au processus de dépréciation et de fin de vie.

Auth0 minimise les perturbations causées par des changements non rétrocompatibles en utilisant le processus suivant :

• Annonce de dépréciation : Auth0 annonce la dépréciation pour informer les clients d’un changement à venir.

• Fenêtre de migration : Les utilisateurs ont au moins six mois pour passer à la nouvelle version des fonctionnalités, et notre procédure de migration leur offre un soutien.

• Fin de vie : Une fois la période de migration terminée, la fonctionnalité déconseillée est transférée vers l’étape de fin de vie et n’est plus accessible.

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’en servir pour les systèmes de production.