Passer au contenu principal
À compter du 23 octobre 2026, Auth0 modifiera le mode de sécurité par défaut des applications tierces nouvellement créées par l’intermédiaire de la Management API. Par défaut, les applications tierces utiliseront des contrôles de sécurité renforcés, conformes aux pratiques exemplaires d’OAuth 2.1.
Ce changement touche uniquement les locataires qui utilisaient des applications tierces avant le 23 avril 2026 et n’a d’incidence que sur les applications nouvellement créées. Vos applications tierces existantes continueront de fonctionner comme aujourd’hui, sans qu’aucune modification soit requise.
Auth0 recommande fortement d’adopter des contrôles de sécurité renforcés pour toutes les nouvelles applications tierces. Ces mesures offrent une autorisation explicite de l’API, l’utilisation obligatoire de PKCE et un ensemble de fonctionnalités ciblé, conforme à OAuth 2.1 et aux pratiques exemplaires en matière de sécurité. Les applications dotées de contrôles de sécurité renforcés bénéficieront également de futures fonctionnalités, comme des limites de débit au niveau de l’application et des outils de gestion améliorés. Toutefois, vous pouvez conserver le comportement actuel au besoin pour des cas d’utilisation précis. Pour en savoir plus sur les applications tierces, consultez Third-Party Applications. Pour une comparaison détaillée de ce qui est offert dans chaque mode, consultez Comparaison des fonctionnalités. Pour obtenir des conseils sur des modèles d’intégration précis, consultez Scénarios courants.

​
En quoi êtes-vous concerné?

Cette migration vous affecte de deux façons :

​
1. Valeur par défaut de la Management API (dépréciation)

Lorsque vous créez des applications tierces au moyen de POST /api/v2/clients, la valeur par défaut de third_party_security_mode passera de permissive (comportement actuel) à strict (contrôles de sécurité renforcés) le 23 octobre 2026. Toutes les applications tierces créées dans l’Auth0 Dashboard utilisent déjà les contrôles de sécurité renforcés. Ce paramètre n’est pas configurable dans l’Auth0 Dashboard.

​
2. enregistrement dynamique des applications (configuration distincte)

Si vous utilisez enregistrement dynamique des applications, les applications DCR sont régies par un paramètre de locataire distinct, dynamic_client_registration_security_mode. Cette configuration est indépendante de la dépréciation et doit faire l’objet d’une décision distincte.

​
Tâches de migration

​
Passez en revue vos applications tierces

Avant de choisir une voie de migration, examinez le fonctionnement de vos applications tierces afin de comprendre leurs exigences actuelles. Tenez compte des éléments suivants :
  • Quels types d’octroi utilisent-elles ? (authorization code, implicite, client credentials, etc.)
  • Ont-elles besoin de scopes OIDC (openid, profile, email) ou de jetons d’identité ?
  • Utilisent-elles Classic Login ou d’anciens points de terminaison ?
  • Comment sont-elles créées ? (manuellement via Auth0 Dashboard ou l’API, ou dynamiquement via DCR)
Si vous avez peu d’applications tierces, vous pouvez les examiner individuellement à l’aide d’Auth0 Dashboard ou de la Management API. Chaque application comporte une propriété third_party_security_mode qui indique son mode de sécurité actuel (strict ou permissive). Renforcez la sécurité des applications permissives existantes : envisagez de passer en revue les stratégies d’accès aux API de vos API et de les régler sur Require Client Grant lorsque c’est approprié. Cela garantit que les applications tierces permissives doivent disposer d’une autorisation explicite pour accéder à ces API. Notez que cette stratégie s’applique aussi aux applications de première partie; examinez donc vos intégrations existantes avant de la modifier. Pour comprendre ce que signifient les contrôles de sécurité renforcés pour vos intégrations, consultez la comparaison des fonctionnalités ci-dessous et vérifiez si votre cas correspond à l’un des scénarios courants. La section FAQ répond également aux questions fréquentes sur la migration.

​
Étape 1 : Choisissez comment créer de nouvelles applications tierces

Déterminez si les nouvelles applications tierces créées au moyen de la Management API doivent utiliser des contrôles de sécurité renforcés ou conserver le comportement actuel. Ce choix s’applique uniquement à POST /api/v2/clients. Les applications créées dans Auth0 Dashboard utilisent toujours des contrôles renforcés. Terminez la migration avant le 23 octobre 2026 pour que les contrôles de sécurité renforcés deviennent le comportement par défaut. Cette approche aligne vos applications tierces sur les pratiques exemplaires d’OAuth 2.1 et les prépare aux fonctionnalités futures.
1. Tester les contrôles de sécurité renforcés
Créez une application tierce de test avec des contrôles de sécurité renforcés pour valider la compatibilité : La réponse inclura un client_id avec le préfixe tpc_ et third_party_security_mode: "strict".
2. Configurer les autorisations d’API par défaut
Les applications tierces avec des contrôles de sécurité renforcés nécessitent des client grants explicites pour accéder aux API. Les autorisations par défaut définissent un ensemble de base d’API et de scopes auquel toutes les applications tierces peuvent accéder automatiquement. C’est particulièrement important pour les applications créées dynamiquement, lorsqu’il n’est pas possible de configurer les autorisations de chaque application individuellement. Vous pouvez également définir des autorisations précises pour des applications particulières (par client_id) afin d’accorder un accès plus large ou plus restreint que celui défini par défaut. Lorsque les deux existent, les autorisations propres à l’application ont priorité sur les autorisations par défaut.
  1. Accédez à Applications > APIs.
  2. Sélectionnez l’API à laquelle les applications tierces doivent accéder.
  3. Sous l’onglet Settings, faites défiler jusqu’à Default Permissions for Third Party Apps.
  4. Sélectionnez Authorized pour User Access et/ou Client Access.
  5. Sélectionnez les scopes à accorder.
  6. Cliquez sur Save.
Vous pouvez configurer des autorisations par défaut distinctes pour les applications tierces selon l’accès utilisateur (subject_type: "user") et l’accès machine à machine (subject_type: "client"). Pour en savoir plus, consultez Autorisations par défaut pour les applications tierces.
3. Valider la compatibilité
Testez vos processus de création d’applications tierces avec les contrôles de sécurité renforcés activés. Confirmez que :
  • Vos applications peuvent utiliser les types d’octroi authorization_code, refresh_token et client_credentials
  • PKCE est implémenté dans vos flux d’autorisation
  • Vous n’avez pas besoin de scopes OIDC
  • Vous n’avez pas besoin de Classic Login ni d’anciens points de terminaison
  • Votre locataire n’a pas de Rules actives qui doivent s’exécuter pour les flux de connexion d’applications tierces. Les Rules ne sont pas prises en charge pour les applications tierces en mode strict et entraîneront une erreur. Si vous utilisez des Rules, envisagez de migrer vers Actions ou d’utiliser le mode permissif.
Si vous constatez des problèmes de compatibilité, consultez Résoudre les problèmes des applications tierces.
4. Terminer la migration
Une fois la compatibilité validée, terminez la migration en désactivant le bouton bascule Create Permissive Third-Party Clients by Default :
Créer des applications tierces permissives par défaut
Dans l’Auth0 Dashboard :
  1. Accédez à Settings > Advanced.
  2. Faites défiler jusqu’à la section Migrations.
  3. Désactivez Create Permissive Third-Party Clients by Default.
  4. Sélectionnez Save.
Après avoir terminé la migration, lorsque vous créez des applications tierces au moyen de POST /api/v2/clients, vous pouvez :
  • Omettre le paramètre third_party_security_mode (les contrôles renforcés s’appliquent par défaut), ou
  • Définir explicitement third_party_security_mode: "strict"
Après le 23 octobre 2026 : le bouton bascule Create Permissive Third-Party Clients by Default sera automatiquement désactivé pour tous les locataires admissibles. Pour créer des applications en conservant le comportement actuel, vous devez explicitement préciser third_party_security_mode: "permissive" dans la requête POST à l’endpoint /api/v2/clients.

​
Option B : conserver le comportement existant par défaut

Si vous devez continuer à créer des applications tierces en conservant le comportement existant par défaut, vous pouvez laisser l’option Create Permissive Third-Party Clients by Default activée jusqu’à ce que vous soyez prêt à adopter des contrôles de sécurité renforcés.
Cette option préserve vos flux de travail actuels, mais n’offre pas les avantages de sécurité des contrôles de sécurité renforcés. Auth0 recommande fortement d’adopter des contrôles de sécurité renforcés pour toutes les nouvelles applications tierces.
Avant l’échéance
Le bouton bascule Créer par défaut des applications tierces permissives reste activé (aucune action n’est requise sur le bouton bascule lui-même). Cependant, vous devez préparer vos flux de travail afin d’indiquer explicitement le mode de sécurité après l’échéance. Mettez à jour votre code de création d’application pour transmettre explicitement third_party_security_mode: "permissive" : Testez cette approche avant l’échéance pour vous assurer que vos flux de travail traitent correctement ce paramètre explicite.
Après la date limite
Le 23 octobre 2026, le bouton bascule Créer par défaut des applications tierces permissives sera automatiquement désactivé. Pour continuer à créer des applications avec le comportement actuel, vous devez définir explicitement third_party_security_mode: "permissive" dans chaque requête POST /api/v2/clients. Si vous omettez le paramètre third_party_security_mode, des contrôles de sécurité renforcés seront appliqués par défaut.

​
Étape 2 : Choisissez comment gérer l’enregistrement dynamique des applications

Si vous utilisez l’enregistrement dynamique des applications, configurez séparément le mode de sécurité des applications DCR. Ce paramètre est indépendant de la modification de la valeur par défaut de la Management API, et vous pouvez le configurer à tout moment.
Avant d’activer les contrôles de sécurité renforcés pour DCR, assurez-vous d’avoir configuré les autorisations d’API par défaut pour les applications tierces. Sans autorisations par défaut, les applications DCR ne pourront accéder à aucune API.

​
Vérifier le comportement DCR actuel

Vérifiez le paramètre actuel du mode de sécurité DCR :
  1. Accédez à Paramètres > Avancé. Sous Mode de sécurité de l’inscription dynamique des applications (DCR), vérifiez la valeur actuelle.
Paramètres avancés du locataire dans le Dashboard avec la liste déroulante du mode de sécurité DCR

​
Configurer le mode de sécurité de DCR

Choisissez le mode de sécurité voulu pour les applications enregistrées dynamiquement : Option A : contrôles de sécurité renforcés pour les applications DCR (recommandé)
Avant d’activer le mode strict pour DCR, configurez les autorisations d’API par défaut pour les applications tierces. Sans autorisations par défaut, les applications DCR ne pourront accéder à aucune API.
Définissez dynamic_client_registration_security_mode sur strict : Option B : conserver le comportement actuel pour les applications DCR Conservez ou définissez dynamic_client_registration_security_mode sur permissive : Pour en savoir plus, consultez l’enregistrement dynamique des applications.

​
Comparaison des fonctionnalités

Le tableau suivant compare les fonctionnalités offertes par chaque mode de sécurité :
FonctionnalitéContrôles de sécurité renforcésComportement actuel
Types d’octroiauthorization_code, refresh_token, client_credentialsTous les types d’octroi sont offerts
PKCEObligatoireFacultatif
OIDCNon disponible. Prévu dans une version ultérieure.Pris en charge
Autorisation de l’APIExige toujours un client grant expliciteSuit la stratégie d’accès de l’API
Classic LoginNon pris en chargePris en charge
Anciens points de terminaisonNon disponiblesDisponibles
Format de l’ID clientPréfixe tpc_Format standard
Propriétés configurablesEnsemble restreint de propriétésToutes les propriétés
Fonctionnalités futuresLimites de débit et futures améliorations en matière de sécurité et de gestionNon disponibles
Création dans Auth0 DashboardUtilise toujours les contrôles renforcésNon disponible dans Auth0 Dashboard

​
Cas d’utilisation courants

​
Scénario 1 : Intégrations partenaires utilisant OAuth moderne

Situation : Vous avez des intégrations partenaires qui utilisent le flux de code d’autorisation avec PKCE et qui accèdent à vos API. Recommandation : Adoptez les contrôles de sécurité renforcés (option A). Cette option est entièrement compatible avec les implémentations OAuth modernes et offre des avantages de sécurité supplémentaires. Étapes :
  1. Configurez les autorisations d’API par défaut pour vos API
  2. Testez la création d’une application partenaire avec third_party_security_mode: "strict"
  3. Terminez la migration en désactivant l’interrupteur de migration

​
Scénario 2 : Applications nécessitant OIDC

Situation : Vos applications tierces nécessitent des scopes OIDC (openid, profile, email) ou des jetons d’identité. Recommandation : La prise en charge d’OIDC pour les applications tierces est prévue dans une version ultérieure. D’ici là, conservez le comportement actuel (option B) ou migrez vers des jetons d’accès avec des scopes d’API. Étapes :
  • Si vous devez utiliser OIDC, laissez l’option de migration activée et transmettez explicitement third_party_security_mode: "permissive" lors de la création des applications
  • Sinon, mettez à jour vos intégrations pour utiliser des scopes d’API plutôt que des scopes OIDC

​
Scénario 3 : Enregistrement dynamique des applications (MCP, agents d’IA)

Situation : Vous utilisez le DCR pour des agents d’IA, des serveurs MCP ou des applications de portail pour développeurs. Recommandation : Configurez dynamic_client_registration_security_mode: "strict" et définissez l’autorisation d’API par défaut. Les applications MCP (Claude Code, VS Code) sont compatibles avec les contrôles de sécurité renforcés. Étapes :
  1. Configurer l’autorisation d’API par défaut
  2. Définir dynamic_client_registration_security_mode: "strict" au moyen de Management API
  3. Tester un enregistrement DCR
  4. Vérifier que les applications DCR peuvent obtenir des jetons d’accès

​
Scénario 4 : Applications utilisant Classic Login

Situation : Vos applications tierces utilisent Classic Login au lieu de Universal Login. Recommandation : Classic Login n’est pas pris en charge pour les applications tierces avec des contrôles de sécurité renforcés. Migrez vers Universal Login ou préservez le comportement existant. Étapes :
  • Recommandé : Migrez vers Universal Login avant d’adopter les contrôles renforcés
  • Solution de rechange : Laissez l’option de migration activée et utilisez explicitement third_party_security_mode: "permissive"

​
Dépannage

Pour savoir comment résoudre les erreurs courantes lors de la migration, consultez Résoudre les problèmes liés aux applications tierces.

​
Foire aux questions

​
Puis-je changer le mode de sécurité d’une application existante?

Non. Le third_party_security_mode est défini lors de la création de l’application et ne peut pas être modifié par la suite. Pour utiliser un autre mode de sécurité, créez une nouvelle application.

​
Qu’arrive-t-il à mes applications tierces existantes?

Rien. Les applications tierces existantes continuent de fonctionner exactement comme aujourd’hui. Cette migration modifie uniquement le paramètre par défaut des nouvelles applications créées.

​
Puis-je utiliser les deux modes de sécurité dans le même locataire?

Oui. Vous pouvez avoir certaines applications tierces avec des contrôles de sécurité renforcés et d’autres avec le comportement actuel. Le mode de sécurité se configure au niveau de chaque application.

​
Qu’en est-il de l’enregistrement dynamique des applications ?

La DCR est contrôlée par un paramètre distinct du locataire, dynamic_client_registration_security_mode. Ce paramètre est indépendant de cette dépréciation et nécessite une décision de configuration distincte. Pour en savoir plus, consultez l’enregistrement dynamique des applications.

​
Puis-je créer des applications qui conservent le comportement existant après la date limite?

Oui, mais uniquement à l’aide de la Management API. Définissez explicitement third_party_security_mode: "permissive" lors de la création de chaque application. Auth0 Dashboard ne permet pas de créer des applications avec le comportement existant.

​
Les fonctionnalités futures fonctionneront-elles avec le comportement actuel?

Certaines fonctionnalités à venir (comme les limites de débit au niveau de l’application) ne seront offertes qu’aux applications dotées de contrôles de sécurité renforcés.

​
En savoir plus