> ## 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.

> Explique le scénario d’architecture dans lequel une application monopage (SPA) communique avec une API à l’aide d’OpenID Connect (OIDC) et du flux d’octroi implicite d’OAuth 2.0 afin d’authentifier les utilisateurs avec Auth0.

# Applications monopages (SPA) avec une API

Dans ce scénario, nous allons créer une API de feuille de temps pour une entreprise fictive nommée ExampleCo. L’API permettra d’ajouter des entrées de feuille de temps pour un employé ou un contractuel.

Nous allons également créer une application monopage (SPA) qui servira à consigner des entrées de feuille de temps et à les envoyer à la base de données centralisée des feuilles de temps au moyen de l’API.

<Info>
  ### En bref

  * Auth0 fournit l’authentification et l’autorisation d’API pour sécuriser l’accès aux points de terminaison d’API (voir [Authentification et autorisation d’API](/fr-CA/docs/get-started/architecture-scenarios/spa-api/part-1#api-authentication-and-authorization))
  * Pour autoriser un utilisateur d’une SPA, Auth0 prend en charge l’octroi implicite (voir [Octroi implicite](/fr-CA/docs/get-started/architecture-scenarios/spa-api/part-1#implicit-grant))
  * La SPA et l’API doivent toutes deux être configurées dans Auth0 Dashboard (voir [Configuration d’Auth0](/fr-CA/docs/get-started/architecture-scenarios/spa-api/part-2#auth0-configuration))
  * Les autorisations utilisateur peuvent être appliquées à l’aide de l’Authorization Extension (voir [Configurer l’Authorization Extension](/fr-CA/docs/get-started/architecture-scenarios/spa-api/part-2#configure-the-authorization-extension))
  * L’API sera sécurisée en veillant à ce qu’un Jeton d’accès valide soit transmis dans l’en-tête HTTP Authorization lors des appels à l’API (voir [Implémenter l’API](/fr-CA/docs/get-started/architecture-scenarios/spa-api/part-3#implement-the-api))
  * La bibliothèque Auth0.js peut être utilisée pour autoriser l’utilisateur de la SPA et obtenir un Jeton d’accès valide pouvant servir à appeler l’API (voir [Autoriser l’utilisateur](/fr-CA/docs/get-started/architecture-scenarios/spa-api/part-3#authorize-the-user))
  * La SPA peut transmettre le Jeton d’accès dans l’en-tête HTTP Authorization lors des appels à l’API (voir [Appeler l’API](/fr-CA/docs/get-started/architecture-scenarios/spa-api/part-3#call-the-api))
  * La SPA peut afficher des éléments d’interface utilisateur de manière conditionnelle selon les scopes accordés à l’utilisateur (voir [Afficher les éléments d’interface utilisateur de manière conditionnelle selon le scope](/fr-CA/docs/get-started/architecture-scenarios/spa-api/part-3#display-ui-elements-conditionally-based-on-scope))
</Info>

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

ExampleCo est une jeune entreprise de consultation. À l’heure actuelle, elle compte environ 100 employés et sous-traite aussi plusieurs activités à des prestataires externes. Tous les employés et les prestataires 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 présenté dans [Authentification unique pour les applications Web classiques](/fr-CA/docs/get-started/architecture-scenarios/sso-for-regular-web-apps). Les employés à l’interne utilisent cette application Web pour remplir leurs feuilles de temps, mais l’entreprise souhaite la remplacer par une SPA. L’application servira à consigner les entrées de feuille de temps et à envoyer les données à la base de données centralisée des feuilles de temps au moyen de l’API. L’application permettra aussi aux gestionnaires d’approuver les entrées de feuille de temps.

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

ExampleCo souhaite mettre en place une solution flexible. Pour le moment, seule une SPA est nécessaire pour saisir les entrées de feuille de temps, mais l’entreprise prévoit lancer à l’avenir d’autres applications, comme une application mobile pour répondre aux besoins de ses équipes de vente. Elle a donc décidé de développer une seule API Timesheets, qui servira à enregistrer le temps non seulement pour ce processus serveur, mais aussi pour toutes les applications futures. Elle veut mettre en place une architecture de sécurité assez souple pour s’adapter à cette réalité. ExampleCo veut s’assurer qu’une grande partie du code et de la logique métier de l’application pourra être partagée entre les différentes applications.

Seuls les utilisateurs et les applications autorisés doivent pouvoir accéder à l’API Timesheets.

Deux types d’utilisateurs utiliseront cette SPA : les employés et les gestionnaires. Les employés doivent pouvoir lire, créer et supprimer leurs propres entrées de feuille de temps, tandis que les gestionnaires doivent aussi pouvoir approuver les feuilles de temps.

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

* [Aperçu de la solution (SPAs + API)](/fr-CA/docs/get-started/architecture-scenarios/spa-api/part-1)
* [Configuration d’Auth0 (SPAs + API)](/fr-CA/docs/get-started/architecture-scenarios/spa-api/part-2)
* [Configuration de l’API et de la SPA (SPAs + API)](/fr-CA/docs/get-started/architecture-scenarios/spa-api/part-3)
* [Implémentation de l’API Node.js (SPAs + API)](/fr-CA/docs/get-started/architecture-scenarios/spa-api/api-implementation-nodejs)
* [Implémentation de la SPA Angular 2 (SPAs + API)](/fr-CA/docs/get-started/architecture-scenarios/spa-api/spa-implementation-angular2)
* [Conclusion (SPAs + API)](/fr-CA/docs/get-started/architecture-scenarios/spa-api/part-4)