> ## 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 où une application monopage (SPA) communique avec une API à l’aide d’OpenID Connect (OIDC) et du flux OAuth 2.0 Implicit Grant pour authentifier les utilisateurs avec Auth0.

# Applications monopages (SPA) avec API

Dans ce scénario, nous allons créer une API de feuilles 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 sous-traitant.

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 des API comme moyen de sécuriser l’accès aux points de terminaison de l’API (voir [Authentification et autorisation de l’API](/docs/fr-ca/get-started/architecture-scenarios/spa-api/part-1#api-authentication-and-authorization))
  * Pour autoriser un utilisateur d’une SPA, Auth0 prend en charge l’Implicit Grant (voir [Implicit Grant](/docs/fr-ca/get-started/architecture-scenarios/spa-api/part-1#implicit-grant))
  * La SPA et l’API doivent toutes deux être configurées dans le Auth0 Dashboard (voir [Auth0 Configuration](/docs/fr-ca/get-started/architecture-scenarios/spa-api/part-2#auth0-configuration))
  * Les Permissions de l’utilisateur peuvent être imposées à l’aide de l’Authorization Extension (voir [Configurer l’Authorization Extension](/docs/fr-ca/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 lorsque des requêtes sont envoyées à l’API (voir [Implémenter l’API](/docs/fr-ca/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](/docs/fr-ca/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 lorsqu’elle envoie des requêtes à l’API (voir [Appeler l’API](/docs/fr-ca/get-started/architecture-scenarios/spa-api/part-3#call-the-api))
  * La SPA peut afficher des éléments de l’interface de façon conditionnelle selon les scopes accordés à l’utilisateur (voir [Afficher des éléments de l’interface de façon conditionnelle selon le scope](/docs/fr-ca/get-started/architecture-scenarios/spa-api/part-3#display-ui-elements-conditionally-based-on-scope))
</Info>

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

ExampleCo est une jeune société de services-conseils. À l’heure actuelle, elle compte environ 100 employés et confie aussi plusieurs activités à des sous-traitants externes. Tous les employés et 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 [Authentification unique pour les applications Web traditionnelles](/docs/fr-ca/get-started/architecture-scenarios/sso-for-regular-web-apps). Les employés l’utilisent 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. Elle permettra aussi aux gestionnaires d’approuver les entrées de feuille de temps.

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

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

Seuls les utilisateurs et les applications autorisés doivent avoir accès à la Timesheets API.

Deux types d’utilisateurs se serviront de cette SPA : les employés et les gestionnaires. Les employés doivent pouvoir consulter, 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)](/docs/fr-ca/get-started/architecture-scenarios/spa-api/part-1)
* [Configuration d’Auth0 (SPAs + API)](/docs/fr-ca/get-started/architecture-scenarios/spa-api/part-2)
* [Configuration de l’API et de la SPA (SPAs + API)](/docs/fr-ca/get-started/architecture-scenarios/spa-api/part-3)
* [Mise en œuvre de l’API en Node.js (SPAs + API)](/docs/fr-ca/get-started/architecture-scenarios/spa-api/api-implementation-nodejs)
* [Mise en œuvre de la SPA Angular 2 (SPAs + API)](/docs/fr-ca/get-started/architecture-scenarios/spa-api/spa-implementation-angular2)
* [Conclusion (SPAs + API)](/docs/fr-ca/get-started/architecture-scenarios/spa-api/part-4)