Paramètres de l’application

Décrit les paramètres des applications offerts dans Auth0 Dashboard.

Dans la page Applications d’Auth0 Dashboard, repérez votre application dans la liste, puis cliquez sur son nom pour afficher les paramètres disponibles.

Les applications tierces disposent d’un ensemble restreint de propriétés configurables. Les propriétés qui ne font pas partie de l’ensemble pris en charge ne peuvent pas être configurées dans Auth0 Dashboard ni au moyen de la Management API. Pour en savoir plus, consultez Contrôles de sécurité pour les applications tierces.

​

Paramètres de base

Lorsque vous modifiez les paramètres d’une application existante ou créez une application, vous saisissez des renseignements sur l’application dans la vue Paramètres.

​

Renseignements de base

• Nom : Le nom de votre application. Il est modifiable et sera visible dans le portail, les courriels, les journaux, etc.
• Domaine : Le nom de votre locataire Auth0. Vous le choisissez lorsque vous créez un nouveau locataire Auth0 et il ne peut pas être modifié. Si vous avez besoin d’un autre domaine, vous devez créer un nouveau locataire en sélectionnant + Create Tenant dans le menu en haut à droite.
• ID client : L’identifiant unique de votre application. Vous l’utiliserez pour configurer l’authentification avec Auth0. Il est généré par le système lorsque vous créez une nouvelle application et ne peut pas être modifié.
• Secret client : Une chaîne utilisée pour signer et valider les ID Tokens dans les flux d’authentification et pour accéder à certains points de terminaison de l’API Auth0. Par défaut, la valeur est masquée; cochez donc la case Reveal Client Secret pour l’afficher. Bien que l’ID client soit considéré comme une information publique, le Secret client doit rester confidentiel. Si quelqu’un a accès à votre Secret client, cette personne peut émettre des jetons et accéder à des ressources auxquelles elle ne devrait pas avoir accès.
• Description : Une description libre de l’objectif de l’application. Maximum de 140 caractères.

​

Propriétés de l’application

• Logo de l’application : l’URL d’un logo (taille recommandée : 150 x 150 pixels) à afficher pour l’application. Il apparaît à plusieurs endroits, notamment dans la liste des applications de l’Auth0 Dashboard et dans les formulaires de consentement personnalisés. Si aucun logo n’est défini, le badge par défaut de ce type d’application s’affiche.

• Propriété de l’application : indique si l’application est de première partie ou tierce. Les applications tierces sont soumises à des contrôles de sécurité renforcés. La propriété de l’application est définie lors de sa création et ne peut pas être modifiée. Pour en savoir plus, consultez Applications de première partie et applications tierces.

• Type d’application : le type d’application Auth0 détermine les paramètres que vous pouvez configurer dans l’Auth0 Dashboard. (Non modifiable pour les applications M2M. Parfois désactivé pour d’autres types d’applications Auth0 si les types d’octroi sélectionnés ne sont autorisés que pour le type d’application actuellement sélectionné.) Utilisez la liste déroulante pour sélectionner l’un des types suivants :

  • Machine à machine : applications non interactives, comme les outils en ligne de commande, les démons, les appareils IoT ou les services exécutés sur votre backend. En général, utilisez cette option si vous avez un service qui doit accéder à une API.
  • Application native : applications mobiles ou de bureau qui s’exécutent nativement sur un appareil (comme iOS ou Android).
  • Application Web standard : applications Web traditionnelles qui exécutent la majeure partie de leur logique applicative sur le serveur (comme Express.js ou ASP.NET).
  • Application Web monopage : applications JavaScript qui exécutent la majeure partie de leur logique d’interface utilisateur dans un navigateur Web et communiquent principalement avec un serveur Web au moyen d’API (comme AngularJS + Node.js ou React).

​

URI de l’application

• URI de connexion de l’application : Dans certains cas, Auth0 doit rediriger vers la page de connexion de votre application. Cette URI doit pointer vers une route de votre application qui redirige vers le point de terminaison /authorize de votre locataire. Elle prend généralement la forme https://myapp.org/login. Vous pouvez utiliser les espaces réservés suivants dans ce champ :

  • Espaces réservés des métadonnées de l’organisation : Utilisez {organization.metadata.KEY} pour renseigner dynamiquement l’URL à partir des métadonnées de l’Organisation Auth0 associée à la requête (par exemple, https://{organization.metadata.public_login_host}/login).
  • Espaces réservés du Domaine personnalisé : Utilisez {custom_domain.metadata.KEY} pour renseigner dynamiquement l’URL à partir des métadonnées du domaine personnalisé utilisé dans la requête (par exemple, https://{custom_domain.metadata.public_app_host}/login).

  Pour en savoir plus, consultez Configurer les routes de connexion par défaut.

• Allowed Callback URLs : Ensemble d’URL vers lesquelles Auth0 est autorisé à rediriger les utilisateurs après leur authentification. Vous pouvez spécifier plusieurs URL valides en les séparant par des virgules (généralement pour gérer différents environnements, comme l’assurance qualité ou les tests). Pour les environnements de production, vérifiez que les URL ne pointent pas vers localhost. Vous pouvez utiliser les espaces réservés suivants dans ce champ :

  • Caractères génériques : Utilisez * pour les sous-domaines (*.google.com) Non recommandé pour les environnements de production.
  • Espaces réservés de l’organisation : Utilisez {organization_name} pour indiquer dynamiquement le nom d’une organisation enregistrée (par exemple, https://{organization_name}.example.com).
  • Espaces réservés du Domaine personnalisé : Utilisez {custom.domain.metadata.KEY} pour renseigner dynamiquement l’URL à partir des métadonnées du domaine personnalisé utilisé dans la requête (par exemple, https://{custom_domain.metadata.public_app_url}/callback).

La première URL indiquée dans ce champ est utilisée comme URL de rappel par défaut lorsque le flux de protocole correspondant n’en précise pas explicitement une. Cela s’applique précisément aux flux SAML, WS-Fed et SSO SAML initié par l’IdP.

N’utilisez pas d’espaces réservés génériques ni d’URL localhost dans les callbacks de votre application ou dans les champs d’origines autorisées. L’utilisation d’URL de redirection avec des espaces réservés génériques peut rendre votre application vulnérable aux attaques. Pour en savoir plus, consultez Unvalidated Redirects and Forwards Cheat Sheet on owasp.org. Le cas échéant, privilégiez plutôt les URL avec l’espace réservé {organization_name}. Pour en savoir plus, consultez Espaces réservés d’URL de sous-domaine.

• Allowed Logout URLs : Après qu’un utilisateur s’est déconnecté d’Auth0, vous pouvez le rediriger à l’aide du paramètre de chaîne de requête returnTo. L’URL utilisée dans returnTo doit être indiquée ici. Vous pouvez spécifier plusieurs URL valides en les séparant par des virgules. Pour les environnements de production, vérifiez que les URL ne pointent pas vers localhost.
  • Caractères génériques : Utilisez * pour les sous-domaines (*.google.com) Non recommandé pour les environnements de production.
  • Espaces réservés de domaine personnalisé : Utilisez {custom.domain.metadata.KEY} pour renseigner dynamiquement l’URL en fonction des métadonnées du domaine personnalisé utilisé dans la requête (par exemple, https://{custom_domain.metadata.public_app_url}/callback).
• Origines Web autorisées : Liste des URL à partir desquelles peut provenir une requête d’autorisation utilisant l’authentification inter-origine, le flux d’appareil et web_message comme mode de réponse. Vous pouvez spécifier plusieurs URL valides en les séparant par des virgules. Pour les environnements de production, vérifiez que les URL ne pointent pas vers localhost. Les chemins, les chaînes de requête et les informations de hash ne sont pas pris en compte lors de la validation de ces URL (et peuvent même faire échouer la correspondance). Vous pouvez fournir jusqu’à 100 URL dans le champ Origines Web autorisées.
  • Caractères génériques : Utilisez * pour les sous-domaines (*.google.com) Non recommandé pour les environnements de production.
  • Espaces réservés de domaine personnalisé : Utilisez {custom.domain.metadata.KEY} pour renseigner dynamiquement l’URL en fonction des métadonnées du domaine personnalisé utilisé dans la requête (par exemple, https://{custom_domain.metadata.public_app_url}/callback).
• Origines autorisées (CORS) : Liste des URL autorisées à effectuer des requêtes Cross-Origin Resource Sharing (CORS) vers Auth0.
  • Espaces réservés de domaine personnalisé : Utilisez {custom.domain.metadata.KEY} pour renseigner dynamiquement l’URL en fonction des métadonnées du domaine personnalisé utilisé dans la requête (par exemple, https://{custom_domain.metadata.public_app_url}/callback).

Si vous configurez les URL de votre application exclusivement à l’aide d’espaces réservés de domaine personnalisé, les requêtes d’authentification effectuées via le domaine canonique de votre locataire (par exemple, https://your-tenant.us.auth0.com) échoueront.

Cela se produit parce que le domaine canonique ne contient pas les métadonnées personnalisées requises pour résoudre l’espace réservé. Assurez-vous que votre application utilise le domaine personnalisé précis pour l’authentification, ou fournissez une URL de secours statique si l’utilisation du domaine canonique est requise.

​

ID Token

Dans la section ID Token, saisissez le délai d’expiration de l’ID Token (en secondes), soit le temps avant l’expiration du id_token d’Auth0. La valeur par défaut est de 36000 secondes, soit 10 heures.

Utilisez Auth0 plutôt que l’IdP pour l’authentification unique : si ce paramètre est activé, Auth0 empêche la redirection des utilisateurs authentifiés ayant des sessions valides vers le fournisseur d’identité (comme Facebook ou ADFS). Anciens locataires uniquement.

​

Rotation des jetons d’actualisation

Dans la section rotation du Jeton d’actualisation, activez ou désactivez la rotation. Lorsqu’elle est activée, l’échange d’un jeton d’actualisation entraîne l’émission d’un nouveau jeton d’actualisation et l’invalidation du jeton existant. Cela permet de détecter automatiquement la réutilisation du jeton s’il est compromis. Saisissez aussi la Période de chevauchement pour la rotation (en secondes). Cet intervalle correspond au délai de tolérance pendant lequel le même refresh_token peut être utilisé pour demander un access_token sans déclencher la détection automatique de réutilisation. Pour en savoir plus, consultez la rotation des jetons d’actualisation.

​

Expiration du jeton d’actualisation

Dans la section Expiration du jeton d’actualisation, activez ou désactivez l’expiration absolue et l’expiration pour inactivité, puis définissez la durée de validité (en secondes) de chacune. Pour en savoir plus, consultez Configurer l’expiration du jeton d’actualisation.

​

Protection contre les redirections ouvertes

Détermine comment Auth0 gère les redirections pour les applications tierces. Ce paramètre n’est offert que pour les applications tierces avec des contrôles de sécurité renforcés.

Lorsqu’elle est activée (par défaut pour les applications tierces), Auth0 ne redirige pas vers l’URL de rappel de l’application en cas d’erreur d’authentification et n’expose pas application.callback_domain dans les modèles de courriel. Cela permet d’éviter les attaques par redirection ouverte lorsque l’URI de redirection est contrôlée par une partie non fiable.

Désactivez la protection contre les redirections ouvertes uniquement pour les applications tierces dont les URI de redirection configurées sont fiables.

Pour en savoir plus, consultez Protection contre les redirections.

​

Paramètres avancés

La section Paramètres avancés vous permet de :

• Gérer ou ajouter les métadonnées de l’application ainsi que les paramètres de l’appareil, d’OAuth et de WS-Federation
• Obtenir des certificats et des renseignements sur le point de terminaison de jeton
• Définir le ou les types d’octroi pour l’application

​

Métadonnées d’application

Les métadonnées d’application sont des clés et des valeurs textuelles personnalisées (chacune comportant un maximum de 255 caractères), définies pour chaque application. Les métadonnées figurent dans l’objet application sous client_metadata, et dans les Rules sous context.clientMetadata. Vous pouvez créer jusqu’à 10 ensembles de métadonnées.

​

Paramètres de l’appareil

Si vous développez une application mobile, saisissez les paramètres iOS/Android requis.

• Si vous développez une application iOS, vous devez fournir votre Team ID et votre App ID. Pour en savoir plus, consultez Activer la prise en charge des liens universels dans Apple Xcode.
• Si vous développez une application Android, vous devez fournir le nom du package de l’application et vos empreintes de hachage de clé. Pour en savoir plus, consultez Activer la prise en charge des liens d’application Android.

​

OAuth

• Par défaut, toutes les applications/API peuvent effectuer une demande de délégation, mais si vous voulez accorder explicitement des autorisations à certaines applications/API, vous pouvez le faire dans Applications/API autorisées.
• Pour les clients qui utilisent l’option Highly Regulated Identity, utilisez le paramètre Niveau d’application de la conformité pour définir votre niveau de conformité. Pour en savoir plus, consultez Configurer la conformité FAPI.
• Confirmation de l’utilisateur final pour l’URI de rappel non vérifiable : utilisez ce paramètre pour déterminer si l’utilisateur doit être invité à confirmer la connexion lorsqu’un URI non vérifiable est utilisé comme URI de rappel. Auth0 recommande de ne pas ignorer la confirmation de l’utilisateur final dans ces cas. Ce paramètre prend le pas sur le paramètre du locataire portant le même nom. Pour en savoir plus, consultez Mesures contre l’usurpation d’application.
• Définissez l’algorithme utilisé (HS256 ou RS256) pour signer vos JSON Web Token. Pour en savoir plus, consultez Algorithmes de signature JSON Web Token. Lorsque vous sélectionnez RS256 (recommandé), le jeton est signé avec la clé privée de votre locataire.
• Activez ou désactivez le paramètre Faire confiance à l’en-tête IP du point de terminaison de jeton; si ce paramètre est activé, auth0-forwarded-for est considéré comme fiable et utilisé comme source d’information sur l’adresse IP de l’utilisateur final afin de protéger le point de terminaison de jeton contre les attaques par force brute. Ce paramètre n’est disponible que pour les applications Web standard et les applications M2M.
• Basculez l’interrupteur pour indiquer si votre application est OIDC Conformant ou non. Les applications marquées comme OIDC Conformant suivront strictement la spécification OIDC.

Pour obtenir de l’aide sur le dépannage, consultez Résoudre les erreurs de jeton invalide.

​

Types d’octroi

Sélectionnez les types d’octroi à activer ou à désactiver pour votre application. Les types d’octroi disponibles dépendent du type d’application et du propriété de l’application. Les applications tierces dotées de contrôles de sécurité renforcés prennent en charge authorization_code, refresh_token et client_credentials.

​

WS-Federation

Gérez ou ajoutez les paramètres WS-Federation.

​

Certificats

Gérez ou ajoutez le certificat de signature, ainsi que son empreinte et son thumbprint.

​

Points de terminaison

Consultez les renseignements sur les points de terminaison pour OAuth, SAML et WS-Fed, notamment les URL d’autorisation et de métadonnées.

​

Pour en savoir plus

• Créer des applications
• Supprimer des applications
• Configurer des applications avec la découverte OIDC
• Applications confidentielles et publiques
• Applications propriétaires et tierces
• Vérifier les messages d’erreur