Contrôles de sécurité pour les applications tierces

Découvrez les contrôles de sécurité qu’Auth0 applique aux applications tierces, notamment OAuth 2.1 et l’autorisation des API.

Auth0 applique des contrôles de sécurité renforcés aux applications tierces afin de garantir ce qui suit :

• Sécurité au niveau du protocole : harmonisation avec les pratiques exemplaires d’OAuth 2.1 pour assurer des flux d’autorisation modernes et sécurisés.
• Portée des fonctionnalités : les applications externes ne peuvent accéder qu’aux ressources que vous autorisez explicitement.

Auth0 renforce régulièrement la sécurité des applications tierces. Seules les fonctionnalités explicitement documentées comme prises en charge doivent être utilisées en production. Les fonctionnalités non prises en charge peuvent être modifiées ou restreintes sans préavis dans de futures mises à jour.

​

Normes OAuth 2.1

Les applications tierces appliquent les normes OAuth modernes :

• PKCE obligatoire : Tous les flux avec code d’autorisation nécessitent Proof Key for Code Exchange. Cela empêche les attaques d’interception du code d’autorisation.
• Types d’octroi pris en charge : authorization_code, refresh_token et client_credentials.
• Octrois implicites et avec mot de passe non pris en charge : Les anciens types d’octroi qui exposent des jetons dans l’URL du navigateur ou exigent la gestion directe des identifiants ne sont pas disponibles pour les applications tierces.

​

Autorisation explicite d’API

Les applications tierces nécessitent toujours une autorisation d’application pour accéder à toute API, quelle que soit la politique d’accès de l’API.

Politique d’accès à l’API	Applications de première partie	Applications tierces
Allow All	Accès accordé	Nécessite une autorisation d’application
Require Client Grant	Nécessite une autorisation d’application	Nécessite une autorisation d’application
Deny	Accès refusé	Accès refusé

Les applications tierces doivent disposer d’un octroi explicite, même lorsqu’une API est configurée avec la politique Allow All. Vous pouvez configurer des autorisations par application ou des autorisations par défaut pour les applications tierces.

Les applications tierces ne peuvent pas se voir accorder l’accès aux API système, comme la Management API ou la My Account API.

​

Machine à machine (Client Credentials)

Les applications tierces prennent en charge le type d’octroi client_credentials pour l’accès machine à machine. Cela permet des intégrations partenaires côté backend et l’accès aux API de serveur à serveur, sans intervention de l’utilisateur.

Exigences et contraintes :

• Type d’application : l’application doit être une application confidentielle (token_endpoint_auth_method ne doit pas être none).
• Organisations : l’accès machine à machine avec les organisations est pris en charge. Une autorisation d’application d’organisation explicite est requise pour chaque organisation. L’option allow_any_organization n’est pas autorisée pour les applications tierces. Les autorisations d’application par défaut pour les applications tierces ne peuvent pas être utilisées pour configurer organization_usage.
• Non disponible pour les applications créées au moyen de Dynamic Client Registration ou de CIMD.
• organization client grant : un lien direct vers la configuration d’une autorisation d’application d’organisation.

Extensibilité :

• Les Actions avec le déclencheur credentials-exchange s’exécutent normalement dans les flux d’accès machine à machine.

​

Configuration restreinte de l’application

Vous ne pouvez configurer qu’un ensemble limité de propriétés d’application pour les applications tierces. Lorsque de nouvelles propriétés sont ajoutées à Auth0, elles ne sont pas disponibles pour les applications tierces, à moins d’avoir été expressément examinées et ajoutées à l’ensemble pris en charge.

Les principales propriétés prises en charge sont les suivantes :

Propriété	Remarques
name, description, logo_uri	Métadonnées de base
callbacks	URI de redirection
allowed_origins, web_origins	Origines CORS et web_message
grant_types	Doit être authorization_code, refresh_token ou client_credentials
token_endpoint_auth_method	Méthode d’authentification pour le point de terminaison du jeton
app_type	Doit être regular_web, spa, native ou non_interactive
client_metadata	Métadonnées personnalisées sous forme de paires clé-valeur
jwt_configuration.lifetime_in_seconds	Durée de vie du jeton d’accès (3600 par défaut)
jwt_configuration.alg	Algorithme de signature (doit être RS256 ; HS256 n’est pas pris en charge)
refresh_token.*	Paramètres de rotation, d’expiration, de tolérance et de durée de vie
client_authentication_methods	JWT avec clé privée (private_key_jwt uniquement ; pas de mTLS)
require_proof_of_possession	Configuration DPoP
redirection_policy	Comportement de redirection pour les flux d’erreur et les modèles de courriel

Pour obtenir la liste complète des propriétés prises en charge, consultez le point de terminaison Create a Client dans la référence du Management API.

​

Format de l’ID client

Les applications tierces se voient attribuer un client_id avec le préfixe tpc_ lors de leur création. Ce préfixe permet à Auth0 de classifier et de gérer séparément le trafic des applications tierces, y compris les limites de débit qui leur sont appliquées.

Le mode de sécurité et l’appartenance de l’application sont des choix de conception permanents :

• third_party_security_mode ne peut pas être modifié après la création.
• Les applications tierces ne peuvent pas être converties en applications de première partie, et inversement.

​

Paramètres du jeton d’actualisation

Les applications tierces appliquent des paramètres sécurisés pour les jetons d’actualisation :

• Expiration requise : Les jetons d’actualisation sans expiration ne sont pas pris en charge. Une durée de vie inactive infinie n’est pas prise en charge.
• Rotation activée par défaut pour les applications publiques : La rotation des jetons d’actualisation est activée par défaut pour les applications tierces de type SPA et natives, conformément aux exigences d’OAuth 2.1 et de MCP.
• Configurable : Les administrateurs peuvent ajuster les paramètres de rotation, de tolérance et de durée de vie pour les applications tierces créées manuellement.

​

Protection contre les redirections

La propriété redirection_policy contrôle la manière dont Auth0 gère les redirections pour les applications tierces. Elle accepte deux valeurs :

Valeur	Comportement
open_redirect_protection (par défaut pour les applications tierces)	Auth0 ne redirige pas vers l’URI de rappel de l’application en cas d’erreur d’authentification. La variable application.callback_domain n’est pas exposée dans les modèles de courriel.
allow_always	Comportement de redirection standard.

Les redirections sans interaction de l’utilisateur peuvent constituer un vecteur d’attaque d’hameçonnage lorsque l’URI de redirection est contrôlée par une partie non fiable (redirection ouverte). Ne définissez redirection_policy sur allow_always que pour les applications dont les URI de rappel configurées sont fiables.

Lorsque open_redirect_protection est actif :

• Les erreurs d’authentification affichent une page d’erreur au lieu de rediriger vers l’application.
• Les modèles de courriel (vérification du courriel, réinitialisation du mot de passe, utilisateur bloqué) n’auront pas accès à {{ application.callback_domain }} ; une valeur de rechange doit donc être configurée pour toute utilisation de {{ application.callback_domain }}. Par exemple :

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

​

Validation des paramètres /authorize

Auth0 valide les paramètres envoyés au point de terminaison /authorize pour les applications tierces. Seuls les paramètres standards d’OAuth 2.0 et d’OpenID Connect sont acceptés.

Paramètres autorisés :

• acr_values
• audience
• authorization_details
• client_id
• code_challenge
• code_challenge_method
• connection
• correlation_id
• display
• dpop_jkt
• ext-* (paramètres personnalisés)
• login_hint
• max_age
• nonce
• prompt
• redirect_uri
• resource
• response_type
• scope
• state
• ui_locales

Non pris en charge :

• claims
• id_token_hint
• invitation
• login_ticket
• request (JAR)
• request_uri (PAR)
• screen_hint

Les requêtes qui contiennent des paramètres non pris en charge renvoient une erreur invalid_request.

​

Compatibilité descendante

Certains locataires qui utilisaient des applications tierces avant avril 2026 peuvent avoir des applications qui fonctionnent avec des paramètres de sécurité différents afin d’assurer la compatibilité descendante. Pour en savoir plus, consultez Permissive Mode for Third-Party Applications.

​

Fonctionnalités non prises en charge

Les fonctionnalités suivantes ne sont pas prises en charge pour les applications tierces :

Fonctionnalité	Statut
scopes OIDC et jetons d’identité	Non pris en charge. Prise en charge prévue dans une version ultérieure.
Point de terminaison /userinfo	Non pris en charge.
API système Auth0 (Management API, MFA API, My Account API, My Orgs API)	Non prises en charge. Les applications tierces ne peuvent pas accéder aux API système dans les flux utilisateur.
MFA pendant l’échange du jeton d’actualisation	Non prise en charge. Les transactions de jeton d’actualisation qui déclenchent MFA entraîneront une erreur.
Rules	Non prises en charge. Les locataires ayant des Rules actives recevront une erreur lorsqu’une application tierce stricte déclenche un flux de connexion.
Hooks (credentials-exchange)	Non pris en charge. Les locataires ayant un Hook credentials-exchange actif recevront une erreur. Migrez vers Actions pour l’extensibilité credentials-exchange.
Points de terminaison non OAuth de l’Authentication API (/dbconnections/*, /passwordless/*)	Non pris en charge.
Points de terminaison hérités (/delegation, /oauth/ro)	Non pris en charge.
SAML, WsFed	Non pris en charge.
Classic Login	Non pris en charge. Utilisez Universal Login.
PAR, CIBA, Device Code	Non pris en charge. Prise en charge prévue dans une version ultérieure.
Points de terminaison de déconnexion	Non pris en charge. Utilisez POST /oauth/revoke pour révoquer les jetons.
Authentification inter-origines	Non prise en charge.
Déconnexion par canal arrière	Non prise en charge. Prise en charge prévue dans une version ultérieure.
Importation d’ID client	Non prise en charge.
Sous-domaines génériques dans les URL	Non pris en charge. Les URL de rappel, les origines autorisées et les origines Web doivent utiliser des URL exactes.

​

En savoir plus

• Applications tierces
• Configurer des applications tierces
• Dépanner les applications tierces
• Accès des applications aux API : autorisations d’application
• Mode permissif pour les applications tierces