En bref
- Auth0 fournit l’authentification et l’autorisation d’API comme moyen de sécuriser l’accès aux points de terminaison de l’API (voir API Authentication and Authorization)
- Pour autoriser un utilisateur d’application mobile et lui accorder l’accès à l’API, Auth0 prend en charge le flux du code d’autorisation avec clé de preuve pour l’échange de code (PKCE) (voir Proof Key for Code Exchange)
- L’application mobile et l’API doivent toutes deux être configurées dans l’Auth0 Dashboard (voir Auth0 Configuration)
- Les permissions utilisateur peuvent être imposées à l’aide de l’Authorization Extension (voir Configurer l’Authorization Extension)
- L’API est sécurisée en veillant à ce qu’un valide soit transmis dans l’en-tête HTTP Authorization lors des requêtes à l’API (voir Implement the API)
- Le SDK Auth0.Android peut être utilisé pour autoriser l’utilisateur de l’application mobile et obtenir un jeton d’accès valide qui peut servir à appeler l’API (voir Autoriser l’utilisateur)
- L’application mobile peut récupérer les renseignements du profil de l’utilisateur en décodant l’ID Token (voir Obtenir le profil de l’utilisateur)
- Les éléments d’interface peuvent être affichés de façon conditionnelle selon le scope accordé à l’utilisateur (voir Afficher les éléments d’interface de façon conditionnelle selon le scope)
- L’application mobile fournit le jeton d’accès dans l’en-tête HTTP Authorization lorsqu’elle fait des requêtes à l’API (voir Appeler l’API)
- Le jeton d’accès de l’utilisateur de l’application mobile peut être renouvelé pour éviter que l’utilisateur ait à se connecter de nouveau pendant une session (voir Renouveler le jeton)
Le principe
ExampleCo est une entreprise de services-conseils en démarrage. Elle compte actuellement environ 100 employés et confie aussi plusieurs activités à des sous-traitants externes. Tous les employés et les sous-traitants externes doivent remplir leurs feuilles de temps chaque semaine. L’entreprise a créé une application de feuilles de temps, un scénario que nous avons abordé dans l’authentification unique pour les applications Web régulières. Les employés à l’interne utilisent cette application Web pour remplir leurs feuilles de temps, mais l’entreprise souhaite offrir une application mobile que les employés et les sous-traitants pourront utiliser lorsqu’ils ne sont pas sur place. L’application servira à consigner les entrées de feuilles de temps et à envoyer les données à la base de données centralisée des feuilles de temps au moyen de l’API. Elle permettra aussi aux gestionnaires d’approuver les entrées de feuilles de temps.Objectifs et exigences
ExampleCo veut mettre en place une solution flexible. Il pourrait y avoir plusieurs employés et sous-traitants qui devront pouvoir consigner des entrées de feuille de temps, ainsi que des traitements par lots qui pourraient téléverser des entrées de feuille de temps depuis d’autres systèmes externes. L’entreprise a donc décidé de développer une seule Timesheets API qui servira à consigner les heures, non seulement pour cette application mobile, mais aussi pour toutes les autres applications. Elle veut mettre en place une architecture de sécurité suffisamment flexible pour répondre à ce besoin. ExampleCo veut s’assurer qu’une grande partie du code et de la logique métier de l’application puisse être partagée entre les différentes applications. Il faut que seuls les utilisateurs et les applications autorisés aient accès à la Timesheets API.En savoir plus
- Vue d’ensemble de la solution (Applications mobiles + API)
- Auth0 Configuration (Applications mobiles + API)
- Configuration de l’API et de l’application mobile (Applications mobiles + API)
- Mise en œuvre de l’API en Node.js (Applications mobiles + API)
- Mise en œuvre de l’application mobile Android (Applications mobiles + API)
- Conclusion (Applications mobiles + API)