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.
- 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
| 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é |
Machine à machine (Client Credentials)
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
| 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 |
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
- 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
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. |
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
/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_valuesaudienceauthorization_detailsclient_idcode_challengecode_challenge_methodconnectioncorrelation_iddisplaydpop_jktext-* (paramètres personnalisés)login_hintmax_agenoncepromptredirect_uriresourceresponse_typescopestateui_locales
Non pris en charge :
claimsid_token_hintinvitationlogin_ticketrequest (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
Fonctionnalités non prises en charge
| 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. |
Authentification
Gérer les utilisateurs
Personnaliser
Auth0 AI
Plateforme