Résoudre les problèmes liés aux applications tierces

Résolvez les erreurs courantes lors de l’utilisation d’applications tierces dans Auth0.

Utilisez cette page pour résoudre les erreurs courantes lors de l’intégration d’applications tierces. Pour un aperçu des fonctionnalités et des restrictions des applications tierces, consultez Contrôles de sécurité pour les applications tierces.

​

Identifier les problèmes liés aux applications tierces

Si vous rencontrez une erreur au cours d’un flux OAuth, vérifiez s’il s’agit d’une application tierce :

• Préfixe de l’ID client : Les applications tierces ont un client_id qui commence par tpc_.
• Journaux du locataire : Dans Auth0 Dashboard > Monitoring > Logs, filtrez par application pour consulter les événements d’erreur.

​

Erreurs courantes

​

unauthorized_client lors de la demande de jetons

Cause : L’application tierce ne dispose pas d’une autorisation client pour l’API demandée. Les applications tierces ont toujours besoin d’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 des autorisations par défaut pour les applications tierces. Pour en savoir plus, consultez Application Access to APIs: Client Grants.

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"
  }'

​

unauthorized_client même avec la politique d’API « Allow All »

Cause : Le paramètre de stratégie d’accès de l’API Allow All s’applique uniquement aux applications propriétaires. Les applications tierces nécessitent toujours une autorisation client explicite, quelle que soit cette option.

Solution : Configurez les autorisations par défaut pour les applications tierces ou créez des autorisations pour chaque application.

​

invalid_request sur /authorize avec des paramètres non pris en charge

Cause : Les applications tierces appliquent une validation stricte des paramètres au 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.

​

unsupported_response_type pour id_token ou token

Cause : Le flux implicite (response_type=token ou response_type=id_token) n’est pas offert pour les applications tierces.

Solution : Utilisez response_type=code avec PKCE.

​

Aucun ID Token renvoyé par /oauth/token

Cause : Les applications tierces dotées de contrôles de sécurité renforcés ne renvoient pas d’ID Token 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 aucun id_token.

Solution : Utilisez des jetons d’accès avec des scopes d’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.

​

Type d’octroi non pris en charge

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

Solution : Pour les flux utilisateur, utilisez le flux de code d’autorisation avec PKCE. Pour l’accès machine à machine, utilisez le flux d’identifiants de l’application avec une application confidentielle (token_endpoint_auth_method ne doit pas être none).

​

Classic Login ne fonctionne pas

Cause : Classic Login n’est pas pris en charge pour les applications tierces.

Solution : Utilisez Universal Login. Universal Login est l’expérience de connexion recommandée pour toutes les applications.

​

L’ID client commence par tpc_

Cause : Les applications tierces reçoivent automatiquement le préfixe tpc_ dans leur ID client aux fins de classification du trafic. Ce préfixe 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 d’ID client plus long.

​

Impossible de modifier is_first_party ou le mode de sécurité

Cause : Le mode de sécurité et le type de propriété de l’application sont des choix de conception permanents définis au moment de sa 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, ou inversement, ni changer son mode de sécurité.

​

La vérification du courriel ou la réinitialisation du mot de passe affiche une page d’erreur

Cause : Le paramètre 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 de courriel.

Solution : Mettez à jour vos modèles de courriel avec une condition Liquid qui prévoit une solution de rechange pour les applications tierces :

{% if application.callback_domain == '' %}
  https://YOUR_FALLBACK_DOMAIN
{% endif %}
{% if application.callback_domain != '' %}
  {{ application.callback_domain }}/result-page
{% endif %}

Vous pouvez aussi définir redirection_policy sur allow_always pour les applications tierces de confiance créées au moyen du Dashboard ou de la Management API. Pour en savoir plus, consultez Contrôles de sécurité pour les applications tierces.

​

L’application DCR ne peut accéder à aucune API

Cause : Des permissions par défaut doivent être configurées pour les applications enregistrées dynamiquement avant qu’elles puissent demander des jetons. Sans permissions par défaut, les applications DCR tierces n’ont accès à aucune API.

Solution : Configurez des permissions par défaut pour les applications tierces sur chaque API à laquelle les applications DCR doivent accéder. Pour en savoir plus, consultez configurer les applications tierces.

​

/userinfo renvoie une erreur

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

Solution : Utilisez des jetons d’accès avec des scopes d’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 prochaine version.

​

/oauth/revoke fonctionne, mais les points de terminaison de déconnexion, non

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

Solution : Utilisez POST /oauth/revoke pour révoquer les jetons d’actualisation. L’application doit effacer elle-même son état de session.

​

Connexion non disponible pour une application tierce

Cause : La connexion n’est pas promue au niveau du domaine. Les applications tierces ne peuvent authentifier les utilisateurs qu’au moyen de connexions au niveau du domaine.

Solution : Promouvez la connexion au niveau du domaine. Pour en savoir plus, consultez Promouvoir des connexions au niveau du domaine.

​

La rotation des jetons d’actualisation pose problème

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

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

​

Pour en savoir plus

• Applications tierces
• contrôle de sécurité pour les applications tierces
• Configurer les applications tierces
• Accès des applications aux API : autorisations d’application