Mesures contre l’usurpation d’identité d’applications

Décrit comment utiliser des liens universels plutôt que des schémas d’URL personnalisés pour vérifier la légitimité des données d’authentification.

Les applications natives utilisent le flux de code d’autorisation avec 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 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’intègrent aucun mécanisme permettant de garantir que l’application qui reçoit la redirection est bien celle prévue. Dans ce scénario, des applications malveillantes usurpent l’identité d’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 de l’existence d’une session légitime antérieure, auquel cas aucune interaction supplémentaire de l’utilisateur n’est nécessaire. PKCE n’aide pas vraiment dans ce type de scénario, puisque l’application malveillante peut lancer le flux de connexion et attendre de recevoir le callback sans interaction de l’utilisateur.

Les applications exécutées sur une machine locale (p. ex., les applications de bureau, les CLI) qui utilisent l’interface de bouclage pour les callbacks (p. ex., http://127.0.0.1:51089/callback ou http://localhost:61024/callback) sont exposées à un risque similaire. Dans ce cas, une autre application sur la même machine pourrait écouter sur le même port afin d’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 réceptrice dans l’un ou l’autre scénario.

​

Mesures d’atténuation recommandées pour les applications mobiles

​

URI HTTPS associées (liens universels / liens d’application)

Les systèmes d’exploitation mobiles modernes prennent en charge les URI HTTPS associées, ce qui vous permet d’associer à votre application mobile un domaine de site Web que vous contrôlez. Les URI HTTPS associées sont appelées :

• Liens universels sur iOS
• Liens d’application sur Android

Les URI HTTPS associées garantissent que seule votre application gère l’URL de rappel associée et protègent contre les accès non autorisés aux données d’authentification sensibles.

Auth0 recommande fortement d’utiliser des URI HTTPS associées comme URI de redirection pour toutes les applications natives.

• Pour iOS : consultez Support Universal Links.
• Pour Android : consultez Android App Links.

​

Mesures d’atténuation recommandées pour toutes les applications

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 des URI HTTPS associé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 défini dans la spécification OAuth2 for Native Apps, Auth0 fournit un mécanisme permettant d’afficher une invite 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’un URI de rappel non vérifiable est utilisé, l’utilisateur est invité à 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 un URI non vérifiable (c.-à-d. un schéma d’URI personnalisé ou un URI de bouclage).
2. Aucun autre écran n’a été présenté à l’utilisateur dans la transaction de connexion en cours (par exemple, lorsqu’un écran de consentement s’affiche pour des applications tierces, ou lorsque MFA est requis).

Dans ces cas, l’application présente à l’utilisateur final une invite de confirmation.

L’invite de confirmation ne s’affiche pas dans les anciens flux non conformes à OIDC. Pour savoir comment appliquer une protection accrue à vos locataires et à vos applications, consultez Adopt OIDC-Conformant Authentication.

​

Personnalisation de l’invite

L’invite de confirmation utilise votre image de marque personnalisée et les configurations définies 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 la part de l’utilisateur ni autre indication que quelque chose s’est produit.

Vous pouvez configurer l’invite de confirmation comme paramètre global du locataire ou au niveau de l’application. Les paramètres au niveau de l’application prévalent sur le paramètre global du locataire.

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 le bouton bascule pour activer l’invite, ou désactivez-le pour la désactiver.

Global

1. Accédez à Auth0 Dashboard > Paramètres > Avancé.
2. Repérez le paramètre Non-Verifiable Callback URI End-User Confirmation.
3. Activez le bouton bascule pour activer l’invite.