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.

​

Identifier les problèmes liés aux applications tierces

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, filtrez par application pour consulter les événements d’erreur.

​

Erreurs courantes

​

unauthorized_client lors d’une demande de jetons

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.

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’accès à l’API « Allow All »

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 ou créez des autorisations propres à chaque application.

​

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

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.

​

unsupported_response_type pour id_token ou token

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.

​

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

​

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 pris en charge.

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 du client avec un client confidentiel (token_endpoint_auth_method ne doit pas être none).

​

Classic Login ne fonctionne pas

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

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

​

Le Client ID commence par tpc_

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.

​

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

​

La vérification de l’e-mail ou la réinitialisation du mot de passe affiche une page d’erreur

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 :

{% 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.

​

Le client DCR n’a accès à aucune API

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.

​

/userinfo renvoie une erreur

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.

​

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

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.

​

Connexion non disponible pour une application tierce

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. Pour les flux basés sur Organization, activez également la connexion pour l’Organization.

​

invalid_request lors de l’authentification via une Organization

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.

​

La rotation des jetons d’actualisation cause des problèmes

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.

​

En savoir plus

• Applications tierces
• Contrôles de sécurité pour les applications tierces
• Configurer les applications tierces
• Accès des applications aux API : autorisations client