> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Scénario d’application Web traditionnelle nécessitant l’authentification des utilisateurs à l’aide de l’authentification unique OpenID Connect (OIDC).

# Applications Web traditionnelles avec authentification unique

Dans ce scénario, nous allons créer une application Web pour une entreprise fictive nommée ExampleCo. L’application est destinée aux employés et aux contractuels d’ExampleCo. Les employés utiliseront leur annuaire d’entreprise existant (Active Directory), tandis que les contractuels seront gérés dans un répertoire d’utilisateurs distinct.

<Info>
  ### En bref

  * Auth0 prend en charge des normes ouvertes comme OAuth 2.0 et <Tooltip tip="OpenID : norme ouverte d’authentification qui permet aux applications de vérifier l’identité des utilisateurs sans recueillir ni stocker les renseignements de connexion." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=OpenID+Connect+%28OIDC%29">OpenID Connect (OIDC)</Tooltip> pour l’authentification et l’autorisation (voir [Quel protocole utiliser](/fr-CA/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-1#which-protocol-to-use))
  * 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](/fr-CA/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-1#authentication-flow))
  * Votre application sera configurée dans Auth0 en tant qu’application (voir [Application](/fr-CA/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-2#application))
  * Les fournisseurs d’identité seront configurés dans Auth0 en tant que Connexion (voir [Connexions](/fr-CA/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-2#connections))
  * Auth0 fournit le widget Lock, qui permet aux utilisateurs de se connecter à l’application (voir [Connexion de l’utilisateur](/fr-CA/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3#user-login))
  * L’application Web doit gérer l’état de la session pour conserver l’information indiquant que l’utilisateur est connecté. En parallèle, Auth0 et le fournisseur d’identité gèrent aussi les renseignements de session. (voir [Gestion des sessions](/fr-CA/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3#session-management))
  * À l’inverse, la déconnexion d’un utilisateur implique aussi trois couches de gestion de session (voir [Déconnexion de l’utilisateur](/fr-CA/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3#user-logout))
  * Le contrôle d’accès peut être géré avec l’Authorization Extension d’Auth0 (voir [Contrôle d’accès](/fr-CA/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3#access-control))
</Info>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Par application Web traditionnelle, nous entendons une application qui utilise principalement le rendu côté serveur, les requêtes de page `GET`, `POST` et les témoins pour maintenir l’état. Cela contraste avec une SPA Web (application monopage), qui repose fortement sur du code JavaScript côté client appelant une API.
</Callout>

<div id="the-premise">
  ## Le contexte
</div>

ExampleCo est une jeune entreprise de services-conseils. À l’heure actuelle, elle compte environ 100 employés et sous-traite aussi plusieurs activités à des entrepreneurs externes. La plupart des employés travaillent au bureau principal de l’entreprise, mais certaines équipes travaillent à distance. De plus, certains employés se rendent fréquemment chez les clients et travaillent à partir d’appareils mobiles.

Tous les employés et les entrepreneurs externes doivent remplir leur feuille de temps chaque semaine à l’aide de tableurs. Le système actuel est inefficace, et l’entreprise a décidé de passer à une solution plus efficace et plus automatisée.

L’entreprise a évalué plusieurs applications de feuilles de temps offertes sur le marché et a conclu qu’il serait plus rentable de créer sa propre solution à l’interne, puisqu’elle cherche pour le moment une application très simple. L’application sera développée avec ASP.NET Core, puisque ses développeurs utilisent déjà cette technologie et peuvent l’avoir prête en une semaine environ.

<div id="goals-requirements">
  ### Objectifs et exigences
</div>

ExampleCo veut lancer rapidement la nouvelle solution. L’entreprise a donc choisi de commencer simplement et de la faire évoluer au fur et à mesure qu’elle recueille les commentaires de ses employés.

L’application doit être accessible uniquement aux utilisateurs connectés. Chaque utilisateur aura un rôle et, selon ce rôle, il pourra effectuer certaines actions et consulter certaines données.

<Info>
  ### Authentification ou autorisation

  ExampleCo veut **authentifier** et **autoriser** chaque utilisateur. L’authentification concerne l’identité : il s’agit de vérifier que l’utilisateur est bien celui qu’il prétend être. L’autorisation consiste à déterminer aux ressources auxquelles un utilisateur peut accéder et ce qu’il est autorisé à faire avec elles.
</Info>

L’application de feuilles de temps d’ExampleCo doit prendre en charge deux rôles : Utilisateur et Admin :

* Une personne ayant le rôle Utilisateur peut ajouter des entrées de feuille de temps en indiquant la date, l’application et le nombre d’heures travaillées. Le rôle Admin a également ce droit.
* Les personnes ayant le rôle Utilisateur ne doivent avoir accès qu’à leurs propres entrées de feuille de temps.
* Une personne ayant le rôle Admin peut aussi :

  * Approuver ou rejeter les entrées de feuille de temps d’autres utilisateurs.
  * Modifier la liste déroulante des applications (ajouter, modifier, supprimer).

Chaque utilisateur devra remplir ses feuilles de temps d’ici la fin de la semaine. Il pourra soit saisir ses feuilles de temps chaque jour, soit ajouter toutes les entrées de la semaine en une seule fois. Les feuilles de temps devront être examinées et approuvées par un Admin. Les entrées rejetées devront être mises à jour par chaque employé, puis soumises de nouveau pour approbation.

L’entreprise utilise Active Directory pour tous ses employés, et ceux-ci se connecteront à l’application Timesheet à l’aide de leurs identifiants Active Directory. 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 d’entreprise d’ExampleCo.

ExampleCo veut réduire au minimum les contraintes liées à la connexion des utilisateurs, tout en maintenant un niveau de sécurité adapté à l’opération : soumettre des entrées de feuille de temps présente moins de risque que de les approuver. Toutefois, les feuilles de temps approuvées servent à facturer les clients, donc la sécurité est bel et bien une exigence. La stratégie d’authentification doit être suffisamment flexible pour s’adapter à la croissance de l’entreprise. Par exemple, l’entreprise devrait pouvoir ajouter facilement des exigences d’authentification supplémentaires, comme l’<Tooltip tip="Authentification multifacteur (MFA) : processus d’authentification de l’utilisateur qui utilise un facteur supplémentaire au nom d’utilisateur et au mot de passe, comme un code envoyé par SMS." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=multi-factor+authentication">authentification multifacteur</Tooltip>, pour les Admins.

La solution doit être accessible autant aux employés présents physiquement au bureau qu’à ceux qui travaillent à distance, sans les contraintes d’une connexion VPN. L’application doit donc être déployée chez un fournisseur infonuagique comme Heroku ou Microsoft Azure.

<Frame>
  <img src="https://mintcdn.com/translations/c0RQ9V0YAcT0-8l5/docs/images/cdy7uua7fh8z/7hg1vqzNEJ2RG1JYw0pxFp/d5e88b45ef76d06b1e8d35ab49186e1d/solution-diagram.png?fit=max&auto=format&n=c0RQ9V0YAcT0-8l5&q=85&s=eb93de36c657e6b0b4c62879897e4792" alt="Schéma de la solution" width="750" height="408" data-path="docs/images/cdy7uua7fh8z/7hg1vqzNEJ2RG1JYw0pxFp/d5e88b45ef76d06b1e8d35ab49186e1d/solution-diagram.png" />
</Frame>

<div id="learn-more">
  ## En savoir plus
</div>

* [Vue d’ensemble de la solution (applications Web + SSO)](/fr-CA/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-1)
* [Configuration d’Auth0 (applications Web + SSO)](/fr-CA/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-2)
* [Implémentation de l’application (applications Web + SSO)](/fr-CA/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3)
* [Implémentation d’ASP.NET Core (applications Web + SSO)](/fr-CA/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/implementation-aspnetcore)
* [Conclusion (applications Web + SSO)](/fr-CA/docs/get-started/architecture-scenarios/sso-for-regular-web-apps/part-4)