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

Découvrez les contrôles de sécurité qu’Auth0 applique aux applications tierces, y compris 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 : conformité aux pratiques exemplaires d’OAuth 2.1 afin de garantir des flux d’autorisation modernes et sécurisés.
• Portée des fonctionnalités : garantir que les applications externes ne puissent 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 étant 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 exigent une clé de preuve pour l’échange de code. Cela empêche les attaques d’interception de code d’autorisation.
• Types d’octroi pris en charge : authorization_code, refresh_token et client_credentials.
• Les octrois implicites et par mot de passe ne sont pas pris en charge : Ces anciens types d’octroi, qui exposent des jetons dans l’URL du navigateur ou exigent la gestion directe des identifiants, ne sont pas offerts pour les applications tierces.

​

Autorisation explicite de l’API

Les applications tierces ont toujours besoin d’un client grant pour accéder à une 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
Tout autoriser	Accès accordé	Nécessite un client grant
Exiger un client grant	Nécessite un client grant	Nécessite un client grant
Refuser	Accès refusé	Accès refusé

Les applications tierces doivent avoir un grant explicite, même lorsqu’une API est configurée avec une politique Tout autoriser. Vous pouvez configurer des permissions par application ou des autorisation par défaut pour les applications tierces.

Les applications tierces ne peuvent pas obtenir d’accès aux API système, comme la Management API ou la My Account API.

​

De machine à machine (Client Credentials)

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

Exigences et contraintes :

• Type de client : l’application doit être un client confidentiel (token_endpoint_auth_method ne doit pas être none).
• Organizations : pris en charge. Pour en savoir plus, consultez Organizations.
• Non disponible pour les applications créées au moyen de Dynamic Client Registration ou de CIMD.

Extensibilité :

• Les Actions avec le déclencheur credentials-exchange s’exécutent comme d’habitude pour les flux d’accès de machine à machine.

​

Organizations

Les applications tierces prennent en charge les Organizations pour les flux utilisateur et l’accès machine à machine. L’accès est offert sur adhésion explicite :

• Flux utilisateur (code d’autorisation) : L’Organization doit activer l’option au moyen de third_party_client_access: allow, et la connexion utilisée pour le login doit être promue au niveau du domaine. Si l’un ou l’autre est absent, Auth0 renvoie invalid_request.
• Machine à machine (Client Credentials) : allow_any_organization n’est pas disponible. Chaque Organization doit être autorisée au moyen d’un organization_client_grant explicite.

Pour configurer cet accès, consultez Configurer l’accès aux Organizations.

​

Configuration restreinte du client

Vous ne pouvez configurer qu’un ensemble limité de propriétés du client pour les applications tierces. Lorsque de nouvelles propriétés sont ajoutées à Auth0, elles ne sont pas disponibles pour les applications tierces, sauf si elles sont 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 de 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 (valeur par défaut : 3600)
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 marge de tolérance et de durée de vie
client_authentication_methods	Private Key JWT (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 de la Management API.

​

Format du Client ID

Les applications tierces reçoivent un client_id avec le préfixe tpc_ au moment de leur création. Ce préfixe permet à Auth0 de classer et de gérer séparément le trafic des applications tierces, y compris les limites de débit qui leur sont propres.

Le mode de sécurité et le type de propriété de l’application sont des choix de conception définitifs :

• 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 vice versa.

​

Paramètres des jetons d’actualisation

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

• Expiration obligatoire : Les jetons d’actualisation sans expiration ne sont pas disponibles. Une durée de vie inactive infinie n’est pas disponible.
• Rotation activée par défaut pour les clients publics : La rotation des jetons d’actualisation est activée par défaut pour les applications tierces SPA et Native, conformément aux exigences d’OAuth 2.1 et du MCP.
• Configurable : Les administrateurs peuvent ajuster les paramètres de rotation, de délai de grâce 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 façon 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 servir de vecteur d’attaque pour l’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 activée :

• 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 solution de secours 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 de /authorize

Auth0 valide les paramètres envoyés au point de terminaison /authorize pour les applications tierces. Seuls les paramètres standard 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 reçoivent une erreur invalid_request.

​

Rétrocompatibilité

Certains tenants 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 rétrocompatibilité. 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 ID	Non pris en charge. Prévu 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 pris en charge. Les applications tierces ne peuvent pas accéder aux API système dans les flux utilisateur.
MFA pendant l’échange de jeton d’actualisation	Non pris en charge. Les transactions de jeton d’actualisation qui déclenchent la MFA entraîneront une erreur.
Rules	Non pris en charge. Les tenants ayant des Rules actives verront une erreur lorsqu’une application tierce stricte déclenche un flux de connexion.
Hooks (credentials-exchange)	Non pris en charge. Les tenants ayant un Hook credentials-exchange actif verront 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. Prévu dans une version ultérieure.
Points de terminaison de logout	Non pris en charge. Utilisez POST /oauth/revoke pour révoquer les jetons.
Authentification cross-origin	Non pris en charge.
Déconnexion par canal arrière	Non pris en charge. Prévu dans une version ultérieure.
Importation de Client ID	Non pris 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 les applications tierces
• Dépannage des applications tierces
• Accès des applications aux API : autorisations des clients
• Mode permissif pour les applications tierces