> ## Documentation Index > Fetch the complete documentation index at: https://docs-staging.auth0-mintlify.app/llms.txt > Use this file to discover all available pages before exploring further. # Migrer vers la sécurité renforcée pour les applications tierces > Découvrez comment les mesures de sécurité renforcées ont une incidence sur les applications tierces existantes et nouvellement créées. export const AuthCodeGroup = ({children, dropdown}) => { const [processedChildren, setProcessedChildren] = useState(children); useEffect(() => { let unsubscribe = null; function init() { unsubscribe = window.autorun(() => { const processChildren = node => { if (typeof node === "string") { let processedNode = node; for (const [key, value] of window.rootStore.variableStore.values.entries()) { const escapedKey = key.replaceAll(/[.*+?^${}()|[\]\\]/g, (String.raw)`\$&`); processedNode = processedNode.replaceAll(new RegExp(escapedKey, "g"), value); } return processedNode; } else if (Array.isArray(node)) { return node.map(processChildren); } else if (node && node.props && node.props.children) { return { ...node, props: { ...node.props, children: processChildren(node.props.children) } }; } return node; }; setProcessedChildren(processChildren(children)); }); } if (window.rootStore) { init(); } else { window.addEventListener("adu:storeReady", init); } return () => { window.removeEventListener("adu:storeReady", init); unsubscribe?.(); }; }, [children]); return {processedChildren}; }; export const AuthCodeBlock = ({filename, icon, language, highlight, children}) => { const [displayText, setDisplayText] = useState(children); const [copyText, setCopyText] = useState(children); const wrapperRef = React.useRef(null); useEffect(() => { let unsubscribe = null; function init() { if (!window.autorun || !window.rootStore) { return; } unsubscribe = window.autorun(() => { let processedChildrenForDisplay = children; let processedChildrenForCopy = children; for (const [key, value] of window.rootStore.variableStore.values.entries()) { const escapedKey = key.replaceAll(/[.*+?^${}()|[\]\\]/g, (String.raw)`\$&`); let displayValue = value; if (key === "{yourClientSecret}" && value !== "{yourClientSecret}") { displayValue = value.substring(0, 3) + "*****MASQUÉ*****"; } processedChildrenForDisplay = processedChildrenForDisplay.replaceAll(new RegExp(escapedKey, "g"), displayValue); processedChildrenForCopy = processedChildrenForCopy.replaceAll(new RegExp(escapedKey, "g"), value); } setDisplayText(processedChildrenForDisplay); setCopyText(processedChildrenForCopy); }); } if (window.rootStore) { init(); } else { window.addEventListener("adu:storeReady", init); } return () => { window.removeEventListener("adu:storeReady", init); unsubscribe?.(); }; }, [children]); useEffect(() => { if (!wrapperRef.current) return; const originalWriteText = navigator.clipboard.writeText.bind(navigator.clipboard); let isOverriding = false; const handleClick = e => { const button = e.target.closest('[data-testid="copy-code-button"]'); if (!button || !wrapperRef.current.contains(button)) return; isOverriding = true; navigator.clipboard.writeText = text => { if (isOverriding) { isOverriding = false; navigator.clipboard.writeText = originalWriteText; return originalWriteText(copyText); } return originalWriteText(text); }; setTimeout(() => { if (isOverriding) { isOverriding = false; navigator.clipboard.writeText = originalWriteText; } }, 100); }; const wrapper = wrapperRef.current; wrapper.addEventListener('click', handleClick, true); return () => { wrapper.removeEventListener('click', handleClick, true); if (navigator.clipboard.writeText !== originalWriteText) { navigator.clipboard.writeText = originalWriteText; } }; }, [copyText]); return
{displayText}
; }; À 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](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1). Ce changement touche uniquement les tenants 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. 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](/docs/fr-ca/get-started/applications/third-party-applications). Pour une comparaison détaillée des options offertes dans chaque mode, consultez [Comparaison des fonctionnalités](#feature-comparison). Pour obtenir des conseils sur des modèles d’intégration précis, consultez [Scénarios courants](#common-scenarios).

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](/docs/fr-ca/get-started/applications/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](/docs/fr-ca/get-started/apis/api-access-policies-for-applications) 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](#feature-comparison) ci-dessous et vérifiez si votre situation correspond à l’un des [scénarios courants](#common-scenarios). La section [FAQ](#frequently-asked-questions) 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. 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.
1. Testez les contrôles de sécurité renforcés
Créez une application tierce de test dotée de contrôles de sécurité renforcés afin de valider la compatibilité : Vous utilisez l’Auth0 CLI? Si ce n’est pas déjà fait, [configurez et authentifiez votre session CLI](/docs/fr-ca/deploy-monitor/auth0-cli) avant d’exécuter cette commande. ```bash Auth0 CLI theme={null} auth0 api post "clients" \ --data '{ "name": "Test Third-Party App", "is_first_party": false, "third_party_security_mode": "strict", "app_type": "regular_web", "callbacks": ["https://partner.example.com/callback"], "grant_types": ["authorization_code", "refresh_token"] }' ``` ```bash cURL theme={null} curl --request POST \ --url 'https://{yourDomain}/api/v2/clients' \ --header 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \ --header 'Content-Type: application/json' \ --data '{ "name": "Test Third-Party App", "is_first_party": false, "third_party_security_mode": "strict", "app_type": "regular_web", "callbacks": ["https://partner.example.com/callback"], "grant_types": ["authorization_code", "refresh_token"] }' ``` La réponse comprendra un `client_id` avec le préfixe `tpc_` et `third_party_security_mode: "strict"`.
2. Configurer les permissions d’API par défaut
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. 1. Accédez à **Applications > APIs**. 2. Sélectionnez l’API à laquelle vous voulez donner accès aux applications tierces. 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**. ```bash Auth0 CLI theme={null} auth0 api post "client-grants" \ --data '{ "default_for": "third_party_clients", "audience": "https://api.example.com", "scope": ["read:items", "write:items"], "subject_type": "user" }' ``` ```bash cURL theme={null} curl --request POST \ --url 'https://{yourDomain}/api/v2/client-grants' \ --header 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \ --header 'Content-Type: application/json' \ --data '{ "default_for": "third_party_clients", "audience": "https://api.example.com", "scope": ["read:items", "write:items"], "subject_type": "user" }' ``` 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](/docs/fr-ca/get-started/applications/application-access-to-apis-client-grants#default-permissions-for-third-party-applications).
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 de points de terminaison hérités * Votre tenant n’a pas de [Rules](/docs/fr-ca/customize/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](/docs/fr-ca/customize/actions/migrate/migrate-from-rules-to-actions) ou utilisez le mode permissif. Si vous relevez des problèmes de compatibilité, consultez [Dépannage des applications tierces](/docs/fr-ca/get-started/applications/third-party-applications/troubleshooting).
4. Terminez la migration
Une fois la compatibilité validée, terminez la migration en désactivant la bascule **Create Permissive Third-Party Clients by Default** : 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. Cette option préserve vos flux de travail actuels, mais n’offre pas les avantages de sécurité des contrôles 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
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"` : ```bash Auth0 CLI theme={null} auth0 api post "clients" \ --data '{ "name": "Partner Integration", "is_first_party": false, "third_party_security_mode": "permissive", "app_type": "regular_web", "callbacks": ["https://partner.example.com/callback"] }' ``` ```bash cURL theme={null} curl --request POST \ --url 'https://{yourDomain}/api/v2/clients' \ --header 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \ --header 'Content-Type: application/json' \ --data '{ "name": "Partner Integration", "is_first_party": false, "third_party_security_mode": "permissive", "app_type": "regular_web", "callbacks": ["https://partner.example.com/callback"] }' ``` Testez cette approche avant l’échéance pour vous assurer que vos workflows gèrent correctement le paramètre explicite.
Après la date limite
À 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](/docs/fr-ca/get-started/applications/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](/docs/fr-ca/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-to-enhanced-security-third-party-applications#1-management-api-default-the-deprecation), et vous pouvez la définir à tout moment. Avant d’activer les contrôles de sécurité renforcés pour DCR, assurez-vous d’avoir configuré les [permissions d’API par défaut](/docs/fr-ca/get-started/applications/application-access-to-apis-client-grants#default-permissions-for-third-party-applications) pour les applications tierces. Sans permissions par défaut, les clients DCR ne pourront accéder à aucune API.

Vérifier le comportement actuel de DCR

Vérifiez le réglage actuel du mode de sécurité DCR : 1. Accédez à **Paramètres > Avancé**. Sous **Dynamic Client Registration (DCR) Security Mode**, vérifiez la valeur actuelle. Paramètres avancés du tenant dans l’Auth0 Dashboard avec liste déroulante DCR Security Mode Faites une requête `GET` au point de terminaison `/api/v2/tenants/settings` pour obtenir les paramètres de votre tenant : ```bash Auth0 CLI theme={null} auth0 api get "tenants/settings" ``` ```bash cURL theme={null} curl --request GET \ --url 'https://{yourDomain}/api/v2/tenants/settings' \ --header 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' ``` Recherchez la propriété `dynamic_client_registration_security_mode` dans la réponse. Si elle est absente, les clients DCR utilisent actuellement le comportement existant par défaut.

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é) Avant d’activer le mode strict pour DCR, configurez les [permissions d’API par défaut](/docs/fr-ca/get-started/applications/application-access-to-apis-client-grants#default-permissions-for-third-party-applications) pour les applications tierces. Sans permissions par défaut, les clients DCR ne pourront accéder à aucune API. Définissez `dynamic_client_registration_security_mode` sur `strict` : ```bash Auth0 CLI theme={null} auth0 api patch "tenants/settings" \ --data '{ "dynamic_client_registration_security_mode": "strict" }' ``` ```bash cURL theme={null} curl --request PATCH \ --url 'https://{yourDomain}/api/v2/tenants/settings' \ --header 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \ --header 'Content-Type: application/json' \ --data '{ "dynamic_client_registration_security_mode": "strict" }' ``` **Option B : Conserver le comportement existant pour les clients DCR** Conservez ou définissez `dynamic_client_registration_security_mode` sur `permissive` : ```bash Auth0 CLI theme={null} auth0 api patch "tenants/settings" \ --data '{ "dynamic_client_registration_security_mode": "permissive" }' ``` ```bash cURL theme={null} curl --request PATCH \ --url 'https://{yourDomain}/api/v2/tenants/settings' \ --header 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \ --header 'Content-Type: application/json' \ --data '{ "dynamic_client_registration_security_mode": "permissive" }' ``` Pour en savoir plus, consultez [Dynamic Client Registration](/docs/fr-ca/get-started/applications/dynamic-client-registration).

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és | Comportement existant | | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------- | | **Types d’octroi** | `authorization_code`, `refresh_token`, `client_credentials` | Tous les types d’octroi offerts | | **PKCE** | Obligatoire | Facultatif | | **OIDC** | Non disponible. Prévu dans une version ultérieure. | Pris en charge | | **Autorisation d’API** | Exige toujours un client grant explicite | Suit la politique d’accès de l’API | | **Classic Login** | Non pris en charge | Pris en charge | | **Points de terminaison hérités** | Non disponibles | Disponibles | | **Format du Client ID** | Préfixe `tpc_` | Format standard | | **Propriétés configurables** | [Ensemble restreint de propriétés](/docs/fr-ca/get-started/applications/third-party-applications/security-controls#restricted-client-configuration) | Toutes les propriétés | | **Organizations (flux utilisateur)** | Pris en charge. L’organisation doit avoir `third_party_client_access: allow` | Non pris en charge | | **Capacité future** | Limites de débit et futures fonctionnalités améliorées de sécurité et de gestion | Non disponibles | | **Création dans le Dashboard** | Utilise toujours les contrôles renforcés | Non disponible dans le Dashboard |

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 : ```bash Auth0 CLI theme={null} auth0 api patch "organizations/{ORG_ID}" \ --data '{ "third_party_client_access": "allow" }' ``` ```bash cURL theme={null} curl --request PATCH \ --url 'https://{yourDomain}/api/v2/organizations/{ORG_ID}' \ --header 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \ --header 'Content-Type: application/json' \ --data '{ "third_party_client_access": "allow" }' ``` 3. [Activez la connexion requise pour l’Organization](/docs/fr-ca/manage-users/organizations/configure-organizations/enable-connections). 4. Configurez [Prompt for Organization ou Organization Domain Discovery](/docs/fr-ca/manage-users/organizations/login-flows-for-organizations) 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](/docs/fr-ca/manage-users/organizations/configure-organizations/enable-third-party-application-access).

Dépannage

Pour savoir comment résoudre les erreurs courantes pendant la migration, consultez [Dépannage des applications tierces](/docs/fr-ca/get-started/applications/third-party-applications/troubleshooting).

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](/docs/fr-ca/get-started/applications/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](/docs/fr-ca/get-started/applications/third-party-applications) * [Contrôles de sécurité pour les applications tierces](/docs/fr-ca/get-started/applications/third-party-applications/security-controls) * [Applications propriétaires et tierces](/docs/fr-ca/get-started/applications/first-party-and-third-party-applications) * [Accès des applications aux API : autorisations client](/docs/fr-ca/get-started/applications/application-access-to-apis-client-grants) * [Dynamic Client Registration](/docs/fr-ca/get-started/applications/dynamic-client-registration) * [Dépannage des applications tierces](/docs/fr-ca/get-started/applications/third-party-applications/troubleshooting) * [Spécification OAuth 2.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1)