Passer au contenu principal
Les applications natives utilisent le flux d’authentification Authorization Code Flow with PKCE et emploient un redirect_uri pour rendre le contrôle à l’application après la connexion. Une fois l’URI chargée dans le navigateur de l’appareil, l’application se rouvre généralement automatiquement pour permettre à l’utilisateur de poursuivre son parcours. Historiquement, les applications mobiles utilisaient des schémas d’URI personnalisés (par exemple, com.mycompany.myapp://oauth2redirect). Cependant, les schémas d’URI personnalisés représentent un risque, car plus d’une application sur l’appareil peut enregistrer le même schéma. Les systèmes d’exploitation mobiles n’incluent pas de mécanismes intégrés pour s’assurer que l’application qui reçoit la redirection est bien celle prévue. Dans ce scénario, des applications malveillantes peuvent usurper des applications légitimes et recevoir la réponse d’autorisation (y compris les jetons) à l’insu de l’utilisateur, en particulier si le SSO (Single Sign-On) est actif en raison de l’existence d’une session légitime précédente, auquel cas aucune interaction supplémentaire de l’utilisateur n’est requise. PKCE n’est pas vraiment utile dans ces scénarios, car l’application malveillante peut initier le flux de connexion et attendre de recevoir le rappel sans interaction de l’utilisateur. Les applications s’exécutant sur une machine locale (par exemple, applications de bureau, interfaces de ligne de commande (CLI)) utilisent l’interface de boucle locale (loopback) pour les rappels (par exemple, http://127.0.0.1:51089/callback ou http://localhost:61024/callback) et sont exposées à un risque similaire. Dans ce cas, une autre application sur la même machine pourrait écouter sur le même port pour intercepter la réponse. Nous appelons à la fois les schémas d’URI personnalisés et les URI de boucle locale des URI de rappel non vérifiables, car le serveur d’autorisation ne peut vérifier l’application destinataire dans aucun de ces scénarios. Les systèmes d’exploitation mobiles modernes prennent en charge les URI HTTPS revendiquées, qui vous permettent d’associer un domaine Web que vous contrôlez à votre application mobile. Les URI HTTPS revendiquées sont appelées :
  • Universal Links sur iOS
  • App Links sur Android
Les URI HTTPS revendiquées garantissent que seule votre application gère l’URL de rappel associée et protègent contre l’accès non autorisé à des données d’authentification sensibles.
Auth0 recommande fortement d’utiliser des URI HTTPS revendiquées comme URI de redirection pour toutes les applications natives.
Auth0 ne peut pas vérifier la légitimité de l’application qui reçoit les résultats de la transaction d’authentification dans les cas suivants :
  • Votre application ne peut pas prendre en charge les URI HTTPS déclarées en raison d’une compatibilité requise avec d’anciennes versions de systèmes d’exploitation mobiles.
  • Votre application est une application de bureau ou une application CLI.
Comme défini dans la spécification OAuth2 for Native Apps, Auth0 fournit un mécanisme pour afficher une demande de confirmation à l’utilisateur. Les utilisateurs confirment que l’application qui reçoit le résultat de l’authentification est bien celle à laquelle ils voulaient accéder. Lorsqu’une URI de rappel non vérifiable est utilisée, l’utilisateur doit vérifier l’application à chaque transaction d’authentification. L’écran de confirmation s’affiche lorsque :
  1. Le redirect_uri présent dans la requête utilise une URI non vérifiable (c.-à-d. un schéma d’URI personnalisé ou une URI de bouclage).
  2. L’utilisateur n’a pas vu d’autre écran dans la transaction de connexion en cours (par exemple lorsqu’un écran de consentement s’affiche pour des applications tierces, ou lorsque l’AMF (MFA) est requise).
Dans ces cas, l’application présente à l’utilisateur final une demande de confirmation.
Mesures contre l’usurpation d’application - Demande de confirmation
La demande de confirmation n’est pas affichée dans les flux hérités non conformes à OIDC. Pour savoir comment appliquer une protection accrue à vos tenants et à vos applications, consultez Adopter l’authentification conforme à OIDC.

​
Personnalisation de l’invite

L’invite de confirmation utilise votre image de marque personnalisée et les paramètres définis pour les écrans de consentement existants utilisés pour les applications tierces. Pour en savoir plus, consultez la section Prompts de Personnaliser les modèles de page Universal Login.
Auth0 recommande fortement de ne pas désactiver cette protection en production. Des applications malveillantes sur l’appareil pourraient demander des id_tokens et des access_tokens sans aucune interaction de l’utilisateur ni autre indication que quelque chose s’est produit.
Vous pouvez configurer l’invite de confirmation en tant que paramètre global du tenant ou au niveau de l’application. Les paramètres au niveau de l’application ont priorité sur le paramètre global au niveau du tenant. Niveau de l’application
  1. Accédez à Auth0 Dashboard > Applications > Application Settings > Advanced > OAuth.
  2. Faites défiler jusqu’au paramètre Non-Verifiable Callback URI End-User Confirmation.
  3. Activez le bouton bascule pour activer l’invite ou désactivez le bouton bascule pour désactiver l’invite.
Auth0 Dashboard>Settings>Advanced
Global
  1. Accédez à Auth0 Dashboard > Settings > Advanced.
  2. Repérez le paramètre Non-Verifiable Callback URI End-User Confirmation.
  3. Activez le bouton bascule pour désactiver l’invite ou désactivez le bouton bascule pour activer l’invite.
Auth0 Dashboard>Tenant Settings>Advanced>Skip Custom URI toggle