> ## 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.

# Résoudre les problèmes des applications tierces

> Résolvez les erreurs courantes lorsque vous travaillez avec des applications tierces dans Auth0.

Utilisez cette page pour corriger les erreurs courantes lors de l’intégration d’applications tierces. Pour un aperçu des capacités et des restrictions des applications tierces, consultez [Contrôles de sécurité pour les applications tierces](/docs/fr-ca/get-started/applications/third-party-applications/security-controls).

<div id="identify-third-party-application-issues">
  ## Identifier les problèmes liés aux applications tierces
</div>

Si vous rencontrez une erreur dans un flux OAuth, vérifiez si l’application est une application tierce :

* **Préfixe du Client ID** : les applications tierces ont un `client_id` qui commence par `tpc_`.
* **Journaux du tenant** : dans [Auth0 Dashboard > Monitoring > Logs](https://manage.auth0.com/#/logs), filtrez par application pour consulter les événements d’erreur.

<div id="common-errors">
  ## Erreurs courantes
</div>

<div id="unauthorized_client-when-requesting-tokens">
  ### `unauthorized_client` lors d’une demande de jetons
</div>

**Cause** : L’application tierce n’a pas d’autorisation client pour l’API demandée. Les applications tierces exigent toujours une autorisation client explicite, même lorsque la politique d’accès à l’API est définie sur **Allow All**.

**Solution** : Créez une autorisation client pour l’application ou configurez l’autorisation par défaut pour les applications tierces. Pour en savoir plus, consultez [Accès des applications aux API : autorisations client](/docs/fr-ca/get-started/applications/application-access-to-apis-client-grants).

```bash theme={null}
curl --request POST \
  --url 'https://YOUR_DOMAIN/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"
  }'
```

<div id="unauthorized_client-even-with-allow-all-api-policy">
  ### `unauthorized_client` même avec la politique d’accès à l’API « Allow All »
</div>

**Cause** : Le paramètre de politique d’accès de l’API **Allow All** s’applique uniquement aux applications de première partie. Les applications tierces nécessitent toujours une autorisation client explicite, quel que soit ce paramètre.

**Solution** : Configurez les [autorisations 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) ou créez des autorisations propres à chaque application.

<div id="invalid_request-on-authorize-with-unsupported-parameters">
  ### `invalid_request` sur `/authorize` avec des paramètres non pris en charge
</div>

**Cause** : Les applications tierces imposent une validation stricte des paramètres sur le point de terminaison `/authorize`. Des paramètres comme `screen_hint`, `login_ticket`, `invitation`, `request` (JAR) et `request_uri` (PAR) ne sont pas pris en charge.

**Solution** : Supprimez les paramètres non pris en charge de votre requête d’autorisation. Pour obtenir la liste des paramètres autorisés, consultez [Contrôles de sécurité pour les applications tierces](/docs/fr-ca/get-started/applications/third-party-applications/security-controls#authorize-parameter-validation).

<div id="unsupported_response_type-for-id_token-or-token">
  ### `unsupported_response_type` pour `id_token` ou `token`
</div>

**Cause** : le flux implicite (`response_type=token` ou `response_type=id_token`) n’est pas pris en charge pour les applications tierces.

**Solution** : utilisez `response_type=code` avec [PKCE](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce).

<div id="no-id-token-returned-from-oauthtoken">
  ### Aucun ID token renvoyé par `/oauth/token`
</div>

**Cause** : Les applications tierces dotées de contrôles de sécurité renforcés ne renvoient pas d’ID tokens et ne traitent pas les scopes OIDC (`openid`, `profile`, `email`) dans cette version. Le point de terminaison de jeton renverra un jeton d’accès, mais pas de `id_token`.

**Solution** : Utilisez des jetons d’accès limités à l’API pour récupérer les renseignements dont votre application a besoin. La prise en charge d’OIDC pour les applications tierces est prévue dans une version ultérieure.

<div id="grant-type-not-supported">
  ### Type d’octroi non pris en charge
</div>

**Cause** : Seuls les types d’octroi `authorization_code`, `refresh_token` et `client_credentials` sont pris en charge. Les types d’octroi comme `implicit`, `password` et `urn:ietf:params:oauth:grant-type:device_code` ne sont pas pris en charge.

**Solution** : Pour les flux utilisateur, utilisez le [Flux de code d’autorisation avec PKCE](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce). Pour l’accès machine à machine, utilisez le [Flux d’identifiants du client](/docs/fr-ca/get-started/authentication-and-authorization-flow/client-credentials-flow) avec un client confidentiel (`token_endpoint_auth_method` ne doit pas être `none`).

<div id="classic-login-not-working">
  ### Classic Login ne fonctionne pas
</div>

**Cause** : [Classic Login](/docs/fr-ca/authenticate/login/auth0-universal-login/universal-login-vs-classic-login/classic-experience) n’est pas pris en charge avec les applications tierces.

**Solution** : Utilisez [Universal Login](/docs/fr-ca/authenticate/login/auth0-universal-login). Universal Login est l’expérience de connexion recommandée pour toutes les applications.

<div id="client-id-starts-with-tpc_">
  ### Le Client ID commence par `tpc_`
</div>

**Cause** : Les applications tierces reçoivent automatiquement le préfixe `tpc_` dans leur Client ID pour la classification du trafic. Il est attribué lors de la création et ne peut pas être modifié.

**Solution** : Il s’agit du comportement attendu. Mettez à jour toute validation côté client ou toute contrainte de base de données afin de prendre en charge le format plus long du Client ID.

<div id="cannot-change-is_first_party-or-security-mode">
  ### Impossible de modifier `is_first_party` ou le mode de sécurité
</div>

**Cause** : Le mode de sécurité et le type de propriété de l’application sont des choix de conception permanents définis à la création. Ils ne peuvent pas être modifiés par la suite.

**Solution** : Créez une nouvelle application avec la configuration souhaitée. Vous ne pouvez pas faire passer une application existante de first-party à third-party, ni d’un mode de sécurité à un autre.

<div id="email-verification-or-password-reset-shows-an-error-page">
  ### La vérification de l’e-mail ou la réinitialisation du mot de passe affiche une page d’erreur
</div>

**Cause** : Le `redirection_policy` de l’application est défini sur `open_redirect_protection`, ce qui empêche Auth0 d’exposer `application.callback_domain` dans les modèles d’e-mails.

**Solution** : Mettez à jour vos modèles d’e-mails en y ajoutant une condition Liquid qui prévoit une solution de secours pour les applications tierces :

```liquid wrap lines theme={null}
{% if application.callback_domain == '' %}
  https://YOUR_FALLBACK_DOMAIN
{% endif %}
{% if application.callback_domain != '' %}
  {{ application.callback_domain }}/result-page
{% endif %}
```

Sinon, réglez `redirection_policy` sur `allow_always` pour les applications tierces de confiance créées dans le Dashboard ou via la Management API. Pour en savoir plus, consultez [Contrôles de sécurité pour les applications tierces](/docs/fr-ca/get-started/applications/third-party-applications/security-controls#redirect-protection).

<div id="dcr-client-cannot-access-any-api">
  ### Le client DCR n’a accès à aucune API
</div>

**Cause** : Les clients enregistrés dynamiquement doivent avoir des autorisations par défaut configurées avant de pouvoir demander des jetons. Sans autorisations par défaut, les clients DCR tiers n’ont aucun accès aux API.

**Solution** : Configurez des autorisations par défaut pour les applications tierces sur chaque API à laquelle les clients DCR doivent accéder. Pour en savoir plus, consultez [Configurer les applications tierces](/docs/fr-ca/get-started/applications/third-party-applications/configure-third-party-applications#default-permissions-for-all-third-party-applications).

<div id="userinfo-returns-error">
  ### `/userinfo` renvoie une erreur
</div>

**Cause** : Le point de terminaison `/userinfo` n’est pas offert pour les applications tierces dans cette version.

**Solution** : Utilisez des jetons d’accès limités aux portées de l’API pour récupérer les renseignements dont votre application a besoin. La prise en charge d’OIDC, y compris `/userinfo`, est prévue dans une version ultérieure.

<div id="oauthrevoke-works-but-logout-endpoints-do-not">
  ### `/oauth/revoke` fonctionne, mais pas les points de terminaison de déconnexion
</div>

**Cause** : Les points de terminaison de déconnexion (`/v2/logout`) ne sont pas disponibles pour les applications tierces.

**Solution** : Utilisez `POST /oauth/revoke` pour révoquer les jetons d’actualisation. L’application doit effacer sa propre session.

<div id="connection-not-available-for-a-third-party-application">
  ### Connexion non disponible pour une application tierce
</div>

**Cause** : Pour les flux sans Organization, la connexion n’a pas été promue au niveau du domaine. Les applications tierces ne peuvent authentifier les utilisateurs qu’à l’aide de connexions au niveau du domaine. Pour les flux basés sur Organization, la connexion doit également être activée pour l’Organization.

**Solution** : Pour les flux sans Organization, promouvez la connexion au [niveau du domaine](/docs/fr-ca/authenticate/identity-providers/promote-connections-to-domain-level). Pour les flux basés sur Organization, [activez également la connexion pour l’Organization](/docs/fr-ca/manage-users/organizations/configure-organizations/enable-connections).

<div id="invalid_request-when-authenticating-through-an-organization">
  ### `invalid_request` lors de l’authentification via une Organization
</div>

**Cause** : l’Organization n’a pas activé l’accès des applications tierces. Par défaut, les Organizations rejettent les requêtes d’authentification provenant d’applications tierces. La requête d’autorisation échoue avec `invalid_request: parameter organization is invalid: {org_id}`.

**Solution** : un administrateur doit activer l’accès des applications tierces pour l’Organization. Pour en savoir plus, consultez [Activer l’accès des applications tierces pour une Organization](/docs/fr-ca/manage-users/organizations/configure-organizations/enable-third-party-application-access).

<div id="refresh-token-rotation-causing-issues">
  ### La rotation des jetons d’actualisation cause des problèmes
</div>

**Cause** : La rotation des jetons d’actualisation est activée par défaut pour les applications tierces publiques (SPA, Native), conformément aux exigences d’OAuth 2.1.

**Solution** : Assurez-vous que votre application gère correctement les jetons d’actualisation avec rotation : chaque échange de jeton doit renvoyer un nouveau jeton d’actualisation et invalider le précédent. Les Admin peuvent ajuster les paramètres de rotation des applications créées manuellement dans le Dashboard ou au moyen de la Management API.

<div id="learn-more">
  ## En savoir plus
</div>

* [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)
* [Configurer les applications tierces](/docs/fr-ca/get-started/applications/third-party-applications/configure-third-party-applications)
* [Accès des applications aux API : autorisations client](/docs/fr-ca/get-started/applications/application-access-to-apis-client-grants)