> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Mode permissif pour les applications tierces
> Découvrez le mode permissif pour les applications tierces et en quoi il diffère des contrôles de sécurité stricts par défaut.
Les clients ayant au moins un tenant qui utilisait des applications tierces avant avril 2026 peuvent avoir des applications qui fonctionnent en mode permissif. Ce mode préserve le comportement préexistant afin d’assurer la rétrocompatibilité.
## Qui peut utiliser le mode permissif
Le mode permissif est offert aux clients qui ont au moins un tenant avec des applications tierces avant avril 2026. Tous les tenants associés au compte de ce client peuvent créer des applications tierces permissives, même ceux qui n’avaient pas auparavant d’applications tierces.
Ces clients peuvent :
* Continuer à utiliser les applications tierces existantes avec leur comportement actuel
* Créer de nouvelles applications tierces avec `third_party_security_mode: "permissive"` au moyen de la Management API
* Créer en tout temps de nouvelles applications avec des contrôles de sécurité renforcés
Les clients sans utilisation antérieure d’applications tierces créent toujours des applications avec des contrôles de sécurité renforcés. Ils ne peuvent pas utiliser le mode permissif.
## Ce que signifie le mode permissif
Les applications tierces en mode permissif se comportent de façon similaire aux applications propriétaires en ce qui concerne les fonctionnalités offertes :
* La plupart des types d’octroi sont disponibles (authorization code, implicit, client credentials, device code)
* Les scopes OIDC et les jetons ID sont pris en charge
* L’accès à l’API est régi par la [politique d’accès](/docs/fr-ca/get-started/apis/api-access-policies-for-applications) configurée pour l’API (sans qu’un client grant soit obligatoire)
* Format de Client ID standard (sans préfixe `tpc_`)
* Toutes les propriétés du client peuvent être configurées
Le mode permissif demande plus d’efforts de configuration de la part de l’administrateur pour appliquer les contrôles de sécurité. Vous êtes responsable de :
* Configurer des [politiques d’accès aux API](/docs/fr-ca/get-started/apis/api-access-policies-for-applications) sur chaque API afin de contrôler quelles applications tierces peuvent y accéder
* Vérifier quels types d’octroi et quelles fonctionnalités sont activés pour chaque application
* Surveiller le comportement des applications tierces au moyen des [journaux du locataire](/docs/fr-ca/deploy-monitor/logs)
## La propriété `third_party_security_mode`
Chaque application tierce possède une propriété `third_party_security_mode` qui indique son mode de sécurité. Cette propriété est définie au moment de sa création et ne peut pas être modifiée.
| **Valeur** | **Signification** |
| ------------ | ----------------------------------------------------------------------------------------------------------------------------------- |
| `strict` | Contrôles de sécurité renforcés. Alignement sur OAuth 2.1, autorisation explicite de l’API, ensemble de fonctionnalités ciblées. |
| `permissive` | Comportement préexistant. Toutes les fonctionnalités sont disponibles, et l’Admin configure manuellement les contrôles de sécurité. |
Les applications tierces créées avant l’introduction des modes de sécurité renvoient `third_party_security_mode: "permissive"` dans les réponses de l’API.
## Comparaison des fonctionnalités
| **Capacité** | **Contrôles de sécurité renforcés (strict)** | **Comportement préexistant (permissive)** |
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |
| **Types d’octroi** | `authorization_code`, `refresh_token`, `client_credentials` | La plupart des types d’octroi (sauf `password`) |
| **PKCE** | Obligatoire | Facultatif |
| **OIDC** | Non pris en charge. Prévu dans une version ultérieure. | Pris en charge |
| **Autorisation de l’API** | Exige toujours un client grant explicite | Suit la politique d’accès à l’API |
| **Classic Login** | Non pris en charge | Pris en charge |
| **Points de terminaison hérités** | Non pris en charge | Disponibles |
| **Format du Client ID** | Préfixe `tpc_` | Format standard |
| **Propriétés configurables** | [Ensemble sélectionné 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és futures** | Limites de débit et futures capacités améliorées de sécurité et de gestion | Non offertes |
| **Création via Dashboard** | Pris en charge | Non offerte via Dashboard |
## Dynamic Client Registration en mode permissif
Si votre compte peut utiliser le mode permissif et que vous utilisez [Dynamic Client Registration](/docs/fr-ca/get-started/applications/dynamic-client-registration), vous pouvez gérer le mode de sécurité des clients enregistrés dynamiquement à l’aide d’un paramètre de tenant distinct.
1. Accédez à **Settings > Advanced**.
2. Sous **Dynamic Client Registration (DCR) Security Mode**, sélectionnez **Permissive**.
3. Sélectionnez **Save**.
```bash 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"
}'
```
Le paramètre `dynamic_client_registration_security_mode` est indépendant du réglage par défaut des applications créées via `POST /api/v2/clients`. Vous pouvez le configurer à tout moment.
Si vous définissez `dynamic_client_registration_security_mode` sur `strict`, configurez d’abord 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). Sinon, les clients enregistrés dynamiquement ne pourront accéder à aucune API.
## Adopter des contrôles de sécurité renforcés
Auth0 recommande d’adopter des contrôles de sécurité renforcés pour toutes les nouvelles applications tierces. La propriété `third_party_security_mode` ne peut pas être modifiée une fois l’application créée — vous ne pouvez pas convertir une application permissive existante en mode strict, ni l’inverse. Vous devez plutôt choisir le mode de sécurité à utiliser au moment de créer de nouvelles applications.
Pour comprendre comment la valeur par défaut des nouvelles applications change et comment vous y préparer, consultez [Migrer vers la sécurité renforcée pour les applications tierces](/docs/fr-ca/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-to-enhanced-security-third-party-applications).
Si vous devez remplacer une application permissive existante par une application stricte, vous devez créer une nouvelle application. Cela invalide tous les jetons d’actualisation existants et toutes les autorisations utilisateur de l’ancienne application. Coordonnez la transition avec la partie tierce afin de minimiser les perturbations.
## 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)
* [Migrer vers la sécurité renforcée pour les applications tierces](/docs/fr-ca/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-to-enhanced-security-third-party-applications)
* [Accès des applications aux API : autorisations client](/docs/fr-ca/get-started/applications/application-access-to-apis-client-grants)
* [Politiques d’accès aux API pour les applications](/docs/fr-ca/get-started/apis/api-access-policies-for-applications)