> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-update-anonymous-sessons-ea.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> 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.
# Mesures contre l’usurpation d’application
Les applications natives utilisent le [flux de code d’autorisation avec PKCE](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-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](https://developers.google.com/identity/protocols/oauth2/native-app#installed_app_redirect_methods) (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](http://127.0.0.1:51089/callback) ou [http://localhost:61024/callback](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.
Mesures d’atténuation recommandées pour les applications mobiles
URI HTTPS revendiquées (Universal Links / App Links)
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.
* Pour iOS : consultez [Support Universal Links](https://developer.apple.com/documentation/xcode/allowing-apps-and-websites-to-link-to-your-content/#Support-universal-links).
* Pour Android : consultez [Android App Links](https://developer.android.com/training/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 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](https://datatracker.ietf.org/doc/html/rfc8252#section-8.6), 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](/docs/fr-ca/get-started/applications/third-party-applications/user-consent-and-third-party-applications) 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.
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](/docs/fr-ca/authenticate/login/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](/docs/fr-ca/customize/login-pages/universal-login/customize-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](https://manage.auth0.com/#/applications/settings).
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.
**Global**
1. Accédez à [Auth0 Dashboard > Paramètres > Avancé](https://manage.auth0.com/#/tenant/advanced).
2. Repérez le paramètre **Non-Verifiable Callback URI End-User Confirmation**.
3. Activez la bascule pour activer l’invite.
