Skip to main content
Les applications natives utilisent le flux de code d’autorisation avec PKCE pour l’authentification et emploient un redirect_uri pour redonner le contrôle à l’application après la connexion. Une fois l’URI chargée dans le navigateur de l’appareil, l’application s’ouvre généralement automatiquement pour permettre à l’utilisateur de poursuivre son parcours. Historiquement, les applications mobiles utilisaient des schémas d’URI personnalisés (p. ex., com.mycompany.myapp://oauth2redirect). Cependant, les schémas d’URI personnalisés pré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’offrent pas de mécanismes intégrés pour garantir que l’application qui reçoit la redirection est bien celle qui était visée. Dans ce scénario, des applications malveillantes se font passer pour des applications légitimes et reçoivent la réponse d’autorisation (y compris les jetons) à l’insu de l’utilisateur, surtout si l’authentification unique (SSO) est active en raison d’une session légitime existante, auquel cas aucune interaction supplémentaire de l’utilisateur n’est requise. PKCE n’est pas vraiment utile dans ces scénarios, puisque l’application malveillante peut lancer le flux de connexion et attendre de recevoir le rappel sans interaction de l’utilisateur. Les applications qui s’exécutent sur une machine locale (p. ex., des applications de bureau, des CLI) utilisent l’interface de bouclage pour les URI de rappel (p. ex., http://127.0.0.1:51089/callback ou http://localhost:61024/callback) et sont exposées à un risque semblable. Dans ce cas, une autre application sur la même machine pourrait écouter sur le même port pour intercepter la réponse. Nous désignons à la fois les schémas d’URI personnalisés et les URI de bouclage comme des URI de rappel non vérifiables, car le serveur d’autorisation ne peut pas vérifier l’application qui les reçoit dans l’un ou l’autre de ces scénarios. Les systèmes d’exploitation mobiles modernes prennent en charge les URI HTTPS revendiquées, ce qui vous permet d’associer à votre application mobile un domaine de site Web que vous contrôlez. 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 peut traiter l’URL de rappel associée et protègent contre tout 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 si :
  • Votre application ne peut pas prendre en charge les URI HTTPS revendiquées en raison de la compatibilité requise avec d’anciennes versions de systèmes d’exploitation mobiles
  • Votre application est une application de bureau ou une application CLI
Comme le définit la spécification OAuth2 for Native Apps, Auth0 fournit un mécanisme permettant d’afficher une invite de confirmation à l’utilisateur. Les utilisateurs confirment ainsi que l’application qui reçoit le résultat de l’authentification est bien celle à laquelle ils voulaient accéder. Lorsqu’un URI de rappel non vérifiable est utilisé, l’utilisateur est invité à vérifier l’application lors de chaque transaction d’authentification. L’écran de confirmation s’affiche lorsque :
  1. Le redirect_uri présent dans la requête utilise un URI non vérifiable (c.-à-d. un schéma d’URI personnalisé ou un URI de bouclage).
  2. L’utilisateur n’a vu aucun autre écran dans la transaction de connexion en cours (par exemple, lorsqu’un écran de consentement s’affiche pour les applications tierces, ou lorsqu’une MFA est requise).
Dans ces cas, l’application affiche une invite de confirmation à l’utilisateur final.
Mesures contre l’usurpation d’applications - Invite de confirmation
L’invite de confirmation n’est pas affichée dans les flux Legacy non conformes à OIDC. Pour savoir comment appliquer une protection renforcée à vos tenants et à vos applications, consultez Adopt OIDC-Conformant Authentication.

​
Personnalisation de l’invite

L’invite de confirmation utilise votre image de marque personnalisée ainsi que les configurations définies pour les écrans de consentement existants utilisés par des applications tierces. Pour en savoir plus, consultez la section Prompts de Customize Universal Login Page Templates.
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 aucun autre signe qu’il s’est passé quelque chose.
Vous pouvez configurer l’invite de confirmation dans les paramètres globaux du tenant ou au niveau de l’application. Les paramètres au niveau de l’application prévalent sur le paramètre global du tenant. Au niveau de l’application
  1. Accédez à Auth0 Dashboard > Applications > Paramètres de l’application > Avancé > OAuth.
  2. Faites défiler jusqu’au paramètre Non-Verifiable Callback URI End-User Confirmation.
  3. Activez la bascule pour activer l’invite, ou désactivez-la pour la désactiver.
Auth0 Dashboard>Paramètres>Avancé
Global
  1. Accédez à Auth0 Dashboard > Paramètres > Avancé.
  2. Repérez le paramètre Non-Verifiable Callback URI End-User Confirmation.
  3. Activez la bascule pour activer l’invite.
Auth0 Dashboard>Tenant Settings>Advanced>Skip Custom URI toggle