Applications Web classiques avec authentification unique
Dans ce scénario, nous allons créer une application Web pour une entreprise fictive appelée ExampleCo. L’application est destinée à être utilisée par les employés et les sous-traitants d’ExampleCo. Les employés utiliseront leur annuaire d’entreprise existant (Entra ID), tandis que les sous-traitants seront gérés dans un magasin d’utilisateurs distinct.
TL;DR
- Auth0 prend en charge les normes ouvertes telles que OAuth 2.0 et OpenID Connect (OIDC) pour l’authentification et l’autorisation (voir Quel protocole utiliser)
- L’OIDC prend en charge plusieurs flux d’autorisation différents - le plus approprié pour les applications Web étant le flux de code d’autorisation (voir Flux d’authentification)
- Votre application sera configurée dans Auth0 en tant qu’application (voir Application)
- Les fournisseurs d’identité seront configurés dans Auth0 en tant que connexion (voir Connexions)
- Auth0 fournit un widget Lock, qui permet aux utilisateurs de se connecter à l’application (voir User Connexion)
- L’application web doit gérer l’état de la session pour garder une trace du fait que l’utilisateur est connecté. Parallèlement, Auth0 et le fournisseur d’identité gèrent également les informations de session. (voir Gestion de session)
- Inversement, la déconnexion d’un utilisateur implique également trois couches de gestion de session (voir Déconnexion de l’utilisateur)
- Le contrôle d’accès peut être géré avec Auth0 Authorization Extension (voir Contrôle d’accès) :::
Par « application Web standard », nous entendons une application qui utilise principalement, du côté serveur, la page GET, POST et des témoins pour maintenir l’état. Cela contraste avec une SPA (Application à page unique) Web, qui repose fortement sur un code JavaScript côté client appelant une API.
Les prémisses
ExampleCo est une société de conseil en démarrage. Elle emploie actuellement une centaine de personnes et confie également plusieurs activités à des sous-traitants externes. La majorité des employés travaillent depuis le siège social de l’entreprise, bien que certaines équipes soient en télétravail. Par ailleurs, certains employés se rendent fréquemment chez les clients et utilisent des appareils mobiles pour travailler.
Tous les employés ainsi que les sous-traitants externes doivent remplir leurs feuilles de temps chaque semaine à l’aide de feuilles de calcul. Le système actuel est inefficace, et l’entreprise a décidé de passer à une solution plus performante et automatisée.
Après avoir évalué plusieurs applications de gestion du temps disponibles, l’entreprise a conclu qu’il serait plus économique de développer sa propre solution interne, étant donné qu’elle recherche une application particulièrement simple. L’application sera développée en utilisant ASP.NET Core, car les développeurs de l’entreprise sont déjà familiarisés avec cette technologie et peuvent avoir l’application prête dans environ une semaine.
Objectifs et exigences
ExampleCo souhaite déployer rapidement la nouvelle solution. C’est pourquoi l’entreprise a opté pour un démarrage simple, avec l’intention de faire évoluer l’application progressivement en fonction des retours d’expérience de ses employés.
L’application doit être accessible uniquement aux utilisateurs connectés. Chaque utilisateur aura un rôle et, en fonction de ce rôle, il devrait pouvoir effectuer certaines actions et afficher des données spécifiques.
::: panneau Authentification vs Autorisation ExampleCo wants to authenticate and authorize each user. L’authentification est reliée à l’identité : elle permet de confirmer que l’utilisateur est bien celui qu’il prétend être. L’autorisation consiste à déterminer les ressources auxquelles un utilisateur doit avoir accès et les actions qu’il est autorisé à effectuer avec ces ressources.
L’application de feuilles de temps d’ExampleCo doit prendre en charge deux rôles : Utilisateur et administrateur :
Une personne disposant du rôle d’utilisateur peut ajouter des entrées dans la feuille de temps, en spécifiant la date, l’application et les heures travaillées. Le rôle d’administrateur dispose également de ce même droit.
Les personnes disposant du rôle d’utilisateur doivent avoir accès uniquement à leurs propres entrées de feuilles de temps.
Une personne disposant du rôle d’administrateur peut également :
Approuver ou rejeter les entrées de feuille de temps d’autres utilisateurs.
Modifier la liste déroulante des valeurs de l’application (ajouter, modifier, supprimer).
Chaque utilisateur devra remplir ses feuilles de temps avant la fin de la semaine. Il peut choisir d’enregistrer quotidiennement ses feuilles de temps ou d’ajouter les entrées dans la même feuille de temps pour toute la semaine. Les feuilles de temps devront être vérifiées et approuvées par un administrateur. Les entrées rejetées devront être mises à jour par chaque employé et soumises à nouveau pour approbation.
L’entreprise utilise Entra ID pour tous les employés et les employés se connecteront à l’application Timesheet à l’aide de leurs informations d’identification Entra ID. Les sous-traitants externes peuvent se connecter avec un nom d’utilisateur et un mot de passe. Les sous-traitants ne figurent pas dans l’annuaire de l’entreprise d’ExampleCo.
ExampleCo souhaite réduire au minimum la charge de connexion des utilisateurs tout en maintenant un niveau de sécurité adapté aux différentes opérations : la soumission des entrées de feuille de temps comporte un risque moindre que leur approbation. Toutefois, étant donné que les feuilles de temps approuvées sont utilisées pour la facturation des clients, la sécurité reste une exigence fondamentale. La stratégie d’authentification doit être flexible afin de pouvoir s’adapter à la croissance de l’entreprise. Par exemple, ils devraient pouvoir ajouter facilement des exigences d’authentification supplémentaires, comme l’authentification multifacteur (MFA), pour les administrateurs.
La solution doit être accessible aussi bien aux employés présents physiquement dans les bureaux de l’entreprise qu’à ceux travaillant à distance, sans les contraintes liées à une connexion VPN. L’application devra donc être déployée sur une plateforme en nuage telle que Heroku ou Microsoft Azure.
