Skip to main content
Les applications mobiles natives peuvent utiliser des flux de connexion natifs, via le navigateur ou les deux au sein de la même application. Dans un flux de connexion via le navigateur, l’utilisateur est redirigé vers un navigateur Web, puis vers la page de connexion Auth0 pour s’inscrire ou se connecter. Par exemple : une application iOS ouvre un SafariViewController ou une application Android ouvre un onglet Chrome personnalisé. Avec un flux de connexion natif, l’utilisateur s’inscrit, se connecte, inscrit des facteurs ou enregistre des clés d’accès directement dans l’application. Les applications natives peuvent utiliser une combinaison de flux de connexion natifs et via le navigateur. Par exemple, vous pouvez utiliser une redirection par navigateur pour la connexion principale ainsi que les API de clés d’accès ou la connexion sociale native pour la réauthentification, l’inscription de facteurs ou l’authentification renforcée dans l’application.

​
Connexion via le navigateur

​
Connexion intégrée dans une application native

Si vous préférez intégrer vos propres pages de connexion à votre application native/mobile, vous pouvez implémenter notre widget de connexion, Lock, directement dans votre application avec :

​
Sans mot de passe

Connexion sans mot de passe intégrée dans les applications natives

​
Éléments à prendre en compte

Lorsque vous mettez en œuvre une connexion intégrée dans une application native avec un formulaire d’identifiants personnalisé, tenez compte des éléments suivants.
  • Hameçonnage/sécurité : Une partie non autorisée pourrait décompiler votre application ou intercepter le trafic entrant ou sortant afin d’obtenir le et l’URL d’authentification. Avec ces renseignements, elle pourrait créer une application malveillante, la téléverser dans une boutique d’applications et l’utiliser pour hameçonner des noms d’utilisateur, des mots de passe et des . Les mesures d’atténuation comprennent l’utilisation de DPoP et des API de clés d’accès afin de lier les jetons et les identifiants à votre client.
  • (SSO) : L’authentification unique entre applications natives nécessite un état de session partagé. Native to Web SSO permet à une application native de partager une session avec une application Web. Le partage direct de jetons entre applications natives au moyen d’un trousseau partagé n’est pas conforme aux spécifications OAuth 2.0.
  • Effort de mise en œuvre : Un formulaire d’identifiants personnalisé peut exiger plus de temps de mise en œuvre que le flux du navigateur système fourni avec les SDK natifs Auth0. De même, lorsque nous publions de nouvelles fonctionnalités qui touchent l’interface de connexion, vous devez les ajouter à l’application et déployer la mise à jour auprès des utilisateurs.
  • Bonnes pratiques OAuth 2.0 (RFC 8252) : La RFC 8252 recommande le recours à des agents utilisateurs externes pour les flux OAuth médiés par navigateur dans les applications natives.
Les approches intégrées modernes, comme les API de clés d’accès et connexion sociale native, reposent sur des échanges de jetons conformes au protocole et évitent la plupart de ces compromis.

​
Connexion sociale native

Vous pouvez ajouter à votre application native une fonctionnalité permettant aux utilisateurs de s’authentifier directement dans l’application auprès de sociaux : Facebook Login : Sign In with Apple :

​
Limites de débit

Les limites s’appliquent uniquement aux requêtes liées aux flux connexion sociale native, qui sont identifiées d’après le corps des requêtes selon les critères initiaux suivants :

​
Limites applicables aux tenants de production des clients payants

​
Limites pour les tenants hors production des clients payants et tous les tenants des clients Free