Migrer vers la sécurité renforcée pour les applications tierces

À partir du 23 octobre 2026, Auth0 changera le mode de sécurité par défaut des applications tierces nouvellement créées au moyen de la Management API. Par défaut, les applications tierces utiliseront des contrôles de sécurité renforcés alignés sur les bonnes pratiques d’OAuth 2.1. Auth0 recommande fortement d’adopter des contrôles de sécurité renforcés pour toutes les nouvelles applications tierces. Les contrôles renforcés offrent une autorisation API explicite, l’utilisation obligatoire de PKCE et un ensemble de fonctionnalités plus ciblé, aligné sur OAuth 2.1 et les bonnes pratiques de sécurité. Les applications dotées de contrôles renforcés profiteront aussi de capacités futures, 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 existant au besoin pour certains cas d’utilisation. Pour en savoir plus sur les applications tierces, consultez Third-Party Applications. Pour une comparaison détaillée des options offertes 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 touche 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 existant) à 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à des contrôles de sécurité renforcés. Cela ne peut pas être configuré dans l’Auth0 Dashboard.

​

2. Dynamic Client Registration (configuration indépendante)

Si vous utilisez Dynamic Client Registration, les clients DCR sont contrôlés par un paramètre de tenant distinct, dynamic_client_registration_security_mode. Ce paramètre est indépendant de la dépréciation et nécessite une décision de configuration distincte.

​

Tâches de migration

​

Passez en revue vos applications tierces

Avant de choisir une voie de migration, passez en revue 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, implicit, client credentials, etc.)
• Ont-elles besoin de scopes OIDC (openid, profile, email) ou d’ID tokens ?
• Utilisent-elles Classic Login ou des points de terminaison hérités ?
• Comment sont-elles créées ? (manuellement via Auth0 Dashboard/API, ou dynamiquement via DCR)

Si vous avez un petit nombre d’applications tierces, vous pouvez les examiner individuellement à l’aide d’Auth0 Dashboard ou de Management API. Chaque application comprend une propriété third_party_security_mode qui indique son mode de sécurité actuel (strict ou permissive). Renforcez les applications permissives existantes : Envisagez de passer en revue les politiques d’accès aux API de vos API et de les définir sur Require Client Grant lorsque c’est approprié. Cela garantit que les applications tierces permissives doivent disposer d’un grant explicite pour accéder à ces API. Notez que cette politique s’applique aussi aux applications de première partie; passez donc en revue vos intégrations existantes avant de la modifier. Pour comprendre ce que les contrôles de sécurité renforcés signifient pour vos intégrations, consultez la comparaison des fonctionnalités ci-dessous et vérifiez si votre situation correspond à l’un des scénarios courants. La section FAQ répond aussi 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 par l’intermédiaire de la Management API doivent utiliser des contrôles de sécurité renforcés ou conserver le comportement existant. Ce choix s’applique uniquement à POST /api/v2/clients. Les applications créées dans l’Auth0 Dashboard utilisent toujours les contrôles renforcés.

​

Option A: Terminer la migration (recommandée)

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 harmonise vos applications tierces avec les pratiques exemplaires d’OAuth 2.1 et les prépare aux capacités futures. Créez une application tierce de test dotée de contrôles de sécurité renforcés afin de valider la compatibilité : La réponse comprendra un client_id avec le préfixe tpc_ et third_party_security_mode: "strict". Les applications tierces assorties de contrôles de sécurité renforcés ont besoin de client grants explicites pour accéder aux API. Les autorisations par défaut définissent un ensemble de base d’API et de scopes auxquels toutes les applications tierces peuvent accéder automatiquement. C’est particulièrement important pour les clients créés dynamiquement, lorsqu’il n’est pas possible de configurer les permissions de chaque application individuellement. Vous pouvez aussi définir des permissions précises pour certaines applications (par client_id) afin d’accorder un accès plus large ou plus restreint que celui accordé par défaut. Lorsque les deux existent, les permissions par application priment sur les permissions par défaut. Vous pouvez configurer des permissions par défaut distinctes pour les applications tierces, selon qu’il s’agit de l’accès utilisateur (subject_type: "user") ou de l’accès machine à machine (subject_type: "client"). Pour en savoir plus, consultez permissions d’API par défaut pour les applications tierces. 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 de points de terminaison hérités
• Votre tenant n’a pas de Rules actifs qui doivent s’exécuter dans les flux de connexion d’applications tierces. Les Rules ne sont pas pris en charge pour les applications tierces en mode strict et entraîneront une erreur. Si vous utilisez Rules, envisagez de migrer vers Actions ou utilisez le mode permissif.

Si vous relevez des problèmes de compatibilité, consultez Dépannage des applications tierces. Une fois la compatibilité validée, terminez la migration en désactivant la bascule Create Permissive Third-Party Clients by Default : Dans l’Auth0 Dashboard :

1. Accédez à Paramètres > Avancé.
2. Faites défiler jusqu’à la section Migrations.
3. Désactivez Create Permissive Third-Party Clients by Default.
4. Sélectionnez Enregistrer.

Une fois la migration terminée, 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 : la bascule Create Permissive Third-Party Clients by Default sera automatiquement désactivée pour tous les tenants admissibles. Pour créer des applications avec le comportement existant, vous devrez explicitement préciser third_party_security_mode: "permissive" dans la requête POST vers le point de terminaison /api/v2/clients.

​

Option B : Conserver le comportement actuel par défaut

Si vous devez continuer à créer des applications tierces en conservant le comportement actuel par défaut, vous pouvez laisser la bascule 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. La bascule Create Permissive Third-Party Clients by Default reste activée (aucune intervention n’est requise sur la bascule elle-même). Toutefois, vous devez préparer vos workflows pour préciser 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 workflows gèrent correctement le paramètre explicite. À compter du 23 octobre 2026, la bascule Create Permissive Third-Party Clients by Default sera automatiquement désactivée. Pour continuer à créer des applications avec le comportement existant, 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 Dynamic Client Registration

Si vous utilisez Dynamic Client Registration, configurez séparément le mode de sécurité des clients DCR. Cette configuration est indépendante du changement de valeur par défaut de la Management API, et vous pouvez la définir à tout moment.

​

Vérifier le comportement actuel de DCR

Vérifiez le réglage actuel du mode de sécurité DCR :

​

Configurer le mode de sécurité de DCR

Choisissez le mode de sécurité à utiliser pour les clients enregistrés dynamiquement : Option A : Contrôles de sécurité renforcés pour les clients DCR (recommandé) Définissez dynamic_client_registration_security_mode sur strict : Option B : Conserver le comportement existant pour les clients DCR Conservez ou définissez dynamic_client_registration_security_mode sur permissive : Pour en savoir plus, consultez Dynamic Client Registration.

​

Comparaison des fonctionnalités

Le tableau suivant compare les fonctionnalités offertes par chaque mode de sécurité :

​

Scénarios 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 mises en œuvre modernes d’OAuth et offre des avantages supplémentaires sur le plan de la sécurité. Étapes :

1. Configurez les permissions 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 la bascule de migration

​

Scénario 2 : applications nécessitant OIDC

Situation : Vos applications tierces nécessitent des scopes OIDC (openid, profile, email) ou des ID tokens. Recommandation : La prise en charge d’OIDC pour les applications tierces est prévue dans une prochaine version. D’ici là, conservez le comportement actuel (option B) ou migrez vers des jetons d’accès limités aux scopes de l’API. Étapes :

• Si vous devez utiliser OIDC, laissez la bascule de migration activée et transmettez explicitement third_party_security_mode: "permissive" lors de la création d’applications
• Sinon, mettez à jour vos intégrations pour utiliser des scopes d’API au lieu de scopes OIDC

​

Scénario 3 : Dynamic Client Registration (MCP, agents d’IA)

Situation : Vous utilisez DCR pour des agents d’IA, des serveurs MCP ou des applications du portail développeur. Recommandation : Configurez dynamic_client_registration_security_mode: "strict" et définissez les permissions d’API par défaut. Les clients MCP (Claude Code, VS Code) sont compatibles avec des contrôles de sécurité renforcés. Étapes :

1. Configurer les permissions d’API par défaut
2. Définir dynamic_client_registration_security_mode: "strict" à l’aide de la Management API
3. Tester un enregistrement DCR
4. Vérifier que les clients DCR peuvent obtenir des jetons d’accès

​

Scénario 4 : Applications utilisant Classic Login

Situation : Vos applications tierces utilisent Classic Login au lieu d’Universal Login. Recommandation : Classic Login n’est pas pris en charge pour les applications tierces soumises à des contrôles de sécurité renforcés. Migrez vers Universal Login ou conservez le comportement existant. Étapes :

• Recommandé : migrez vers Universal Login avant d’adopter les contrôles renforcés
• Alternative : laissez la bascule de migration activée et utilisez explicitement third_party_security_mode: "permissive"

​

Scénario 5 : Applications tierces avec Organizations

Situation : Vous souhaitez que des applications tierces (intégrations partenaires, agents d’IA) authentifient les utilisateurs dans un contexte organisationnel. Recommandation : Adoptez les contrôles de sécurité renforcés. La prise en charge d’Organizations pour les applications tierces n’est pas offerte avec le comportement existant. Configurez third_party_client_access: allow pour chaque Organization devant autoriser l’accès par des tiers. Étapes :

1. Assurez-vous que l’application tierce utilise les contrôles de sécurité renforcés (third_party_security_mode: "strict").
2. Configurez third_party_client_access: allow pour l’Organization :

3. Activez la connexion requise pour l’Organization.
4. Configurez Prompt for Organization ou Organization Domain Discovery afin de garantir que les utilisateurs sont dirigés vers le bon contexte d’Organization, car vous ne pouvez pas vous fier à l’application externe pour transmettre le paramètre organization.

Pour en savoir plus, consultez Enable Third-Party Application Access for an Organization.

​

Dépannage

Pour savoir comment résoudre les erreurs courantes pendant la migration, consultez Dépannage des applications tierces.

​

Foire aux questions

​

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

Non. Le third_party_security_mode est défini au moment 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 n’affecte que le mode par défaut des applications nouvellement créées.

​

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

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

​

Qu’en est-il de Dynamic Client Registration?

Le DCR est régi par un paramètre de tenant distinct, dynamic_client_registration_security_mode. Ce paramètre est indépendant de la dépréciation et nécessite une décision de configuration distincte. Pour en savoir plus, consultez Dynamic Client Registration.

​

Puis-je créer des applications avec 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. L’Auth0 Dashboard ne permet pas de créer d’applications avec le comportement existant.

​

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

Certaines fonctionnalités futures (comme les limites de taux par application) ne seront offertes qu’aux applications dotées de contrôles de sécurité renforcés.

​

En savoir plus

• Applications tierces
• Contrôles de sécurité pour les applications tierces
• Applications propriétaires et tierces
• Accès des applications aux API : autorisations client
• Dynamic Client Registration
• Dépannage des applications tierces
• Spécification OAuth 2.1