Paramètres de l’application

Décrit les paramètres liés aux applications offerts dans l’Auth0 Dashboard.

Sur la page Applications du 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 des propriétés prises en charge ne peuvent pas être configurées dans l’Auth0 Dashboard ni au moyen de la Management API. Pour en savoir plus, consultez Mesures de sécurité pour les applications tierces.

​

Paramètres de base

Lorsque vous modifiez les paramètres d’une application existante ou que vous créez une nouvelle application, vous entrez les renseignements relatifs à l’application dans la vue Settings.

​

Renseignements de base

• Name : Le nom de votre application. Il peut être modifié et sera visible dans le portail, les courriels, les logs, etc.
• Domain : Le nom de votre tenant Auth0. Vous le choisissez lorsque vous créez un nouvel tenant Auth0 et il ne peut pas être modifié. Si vous avez besoin d’un autre domaine, vous devez créer un nouveau tenant en sélectionnant + Create Tenant dans le menu en haut à droite.
• Client ID : 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é.
• Client Secret : Une chaîne utilisée pour signer et valider les jetons d’identification dans les flux d’authentification et pour obtenir l’accès à certains points de terminaison de l’API Auth0. Par défaut, cette valeur est masquée; cochez donc la case Reveal Client Secret pour l’afficher. Bien que le Client ID soit considéré comme de l’information publique, le Client Secret doit demeurer confidentiel. Si quelqu’un a accès à votre Client Secret, cette personne peut émettre des jetons et accéder à des ressources auxquelles elle ne devrait pas avoir accès.
• Description : Une description en texte 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 du Dashboard et dans les formulaires de consentement personnalisés. Si aucun logo n’est défini, l’insigne par défaut de ce type d’application s’affichera.

• 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 la création et ne peut pas être modifiée. Pour en savoir plus, consultez Applications de première partie et tierces.

• Type d’application : le type d’application Auth0 détermine les paramètres que vous pouvez configurer dans le Dashboard. (Non modifiable pour les applications M2M. Parfois désactivé pour d’autres types d’application Auth0 si les types d’octroi sélectionnés sont autorisés uniquement pour le type d’application actuellement choisi.) 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, vous utiliserez 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 traditionnelle : applications Web traditionnelles qui exécutent la majeure partie de leur logique sur le serveur (comme Express.js ou ASP.NET).
  • Application monopage : applications JavaScript qui exécutent la majeure partie de leur logique d’interface utilisateur dans un navigateur Web, en communiquant avec un serveur Web principalement au moyen d’API (comme AngularJS + Node.js ou React).

​

URI de l’application

• Application Login URI : Dans certains cas, Auth0 doit rediriger votre application vers sa page de connexion. Cette URI doit pointer vers une route de votre application qui redirige vers le point de terminaison /authorize de votre tenant endpoint. Elle prendra 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 de métadonnées d’organisation : Utilisez {organization.metadata.KEY} pour renseigner dynamiquement l’URL à partir des métadonnées de l’Auth0 Organization associée à la requête (par exemple, https://{organization.metadata.public_login_host}/login).
  • Espaces réservés de 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 peut rediriger les utilisateurs après leur authentification. Vous pouvez indiquer plusieurs URL valides en les séparant par des virgules (généralement pour gérer différents environnements, comme l’AQ 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 d’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 de 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 plus précisément aux flux SAML, WS-Fed et IdP-Initiated SSO de SAML 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 des origines autorisées. L’utilisation d’URL de redirection avec des espaces réservés génériques peut rendre votre application vulnérable à des attaques. Pour en savoir plus, consultez Unvalidated Redirects and Forwards Cheat Sheet on owasp.org. Lorsque c’est pertinent, 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 : Lorsqu’un utilisateur se déconnecte d’Auth0, vous pouvez le rediriger à l’aide du paramètre de requête returnTo. L’URL utilisée dans returnTo doit être indiquée ici. Vous pouvez préciser 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 à partir des métadonnées du domaine personnalisé utilisé dans la requête (par exemple, https://{custom_domain.metadata.public_app_url}/callback).
• Allowed Web Origins : Liste des URL à partir desquelles peut provenir une requête d’autorisation utilisant Cross-Origin Authentication, Device Flow et web_message comme mode de réponse. Vous pouvez préciser 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 hachage 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 Allowed Web Origins.
  • 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 à partir des métadonnées du domaine personnalisé utilisé dans la requête (par exemple, https://{custom_domain.metadata.public_app_url}/callback).
• Allowed Origins (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 à partir 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 tenant (par exemple, https://your-tenant.us.auth0.com) échoueront.

Cela se produit parce que le domaine canonique ne possède 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 statique de solution de secours si l’utilisation du domaine canonique est requise.

​

ID Token

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

Utiliser Auth0 au lieu de l’IdP pour l’authentification unique : si ce paramètre est activé, Auth0 ne redirige pas les utilisateurs authentifiés ayant une session valide vers le fournisseur d’identité (comme Facebook ou ADFS). Pour les tenants Legacy uniquement.

​

Rotation des jetons d’actualisation

Dans la section jeton d’actualisation Rotation, activez ou désactivez la rotation. Lorsqu’elle est activée, chaque é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 d’un jeton s’il est compromis. De plus, saisissez la période de chevauchement de 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 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 disponible 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 de redirection ouverte lorsque l’URI de redirection est contrôlé par une partie non fiable.

Ne désactivez la protection contre les redirections ouvertes que pour les applications tierces dont les URI de rappel configurés 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 des métadonnées d’application, des paramètres device, OAuth et WS-Federation
• Obtenir des certificats et des renseignements sur le point de terminaison des jetons
• Définir le ou les types d’octroi pour l’application

​

Métadonnées de l’application

Les métadonnées de l’application sont des clés et des valeurs de type chaîne personnalisées (chacune pouvant contenir au maximum 255 caractères), définies pour chaque application. Les métadonnées sont exposées 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.

​

Device Settings

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

• Si vous développez des applications iOS, vous devrez 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 des applications Android, vous devrez fournir votre App Package Name et vos hachages de clés. Pour en savoir plus, consultez Activer la prise en charge d’Android App Links.

​

OAuth

• Par défaut, toutes les applications/API peuvent effectuer une requête de délégation, mais si vous souhaitez accorder explicitement des permissions à certaines applications/API, vous pouvez le faire dans Applications/API autorisées.
• Pour les clients qui utilisent le module complémentaire Highly Regulated Identity, utilisez le paramètre Compliance Enforcement Level pour définir votre niveau de conformité. Pour en savoir plus, consultez Configurer la conformité FAPI.
• Non-Verifiable Callback URI End-User Confirmation : 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 a préséance sur le paramètre du tenant portant le même nom. Pour en savoir plus, consultez Measures Against Application Impersonation.
• Définissez l’algorithme utilisé (HS256 ou RS256) pour signer vos JSON Web Tokens. Pour en savoir plus, consultez Algorithmes de signature des JSON Web Tokens. Lorsque vous sélectionnez RS256 (recommandé), le jeton est signé avec la clé privée de votre tenant.
• Activez ou désactivez le paramètre Trust Token Endpoint IP Header; s’il est activé, auth0-forwarded-for est considéré comme fiable et utilisé comme source d’information sur l’adresse IP de l’utilisateur final pour la protection contre les attaques par force brute sur le point de terminaison de jeton. Ce paramètre est offert uniquement pour les applications Web traditionnelles et les applications M2M.
• Utilisez le commutateur pour indiquer si votre application est OIDC Conformant ou non. Les applications marquées comme OIDC Conformant suivront strictement la spécification OIDC.

​

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 de la 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 numérique et son empreinte.

​

Points de terminaison

Consultez les informations sur les points de terminaison pour OAuth, SAML, et WS-Fed, comme les URL Authorization et Metadata.

​

En savoir plus

• Créer des applications
• Supprimer des applications
• Configurer les applications avec OIDC Discovery
• Applications confidentielles et publiques
• Applications de première partie et tierces