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

> Aperçu de la solution pour le scénario d’architecture SPAs + API

# Aperçu de la solution (SPAs + API)

Afin de s’assurer que seuls les utilisateurs et les applications autorisés peuvent accéder à la Timesheets API, ExampleCo a décidé d’utiliser le [cadre d’autorisation OAuth 2.0](https://tools.ietf.org/html/rfc6749). Ce cadre offre à l’entreprise la souplesse recherchée, puisque les différents types d’octroi lui permettent d’autoriser facilement les divers types d’applications qui doivent communiquer avec la Timesheets API.

<div id="api-authentication-and-authorization">
  ## Authentification et autorisation de l’API
</div>

Une API permet d’exposer les fonctionnalités de votre application à d’autres applications. Une application peut envoyer une requête à un point de terminaison d’une API et recevoir des informations en réponse.

Un point de terminaison d’API peut être sécurisé ou non. Dans notre cas, puisque les feuilles de temps contiennent des renseignements sensibles qui ont une incidence sur les évaluations et les paiements, il est important de s’assurer que seuls les utilisateurs et les applications autorisés peuvent appeler les points de terminaison de notre API. Lorsqu’une application cliente veut accéder à des points de terminaison protégés d’une API, elle doit présenter un <Tooltip tip="Jeton d’accès : justificatif d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisé pour accéder à une API." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Access+Token">jeton d’accès</Tooltip> comme preuve qu’elle possède les permissions requises pour effectuer la requête vers le point de terminaison.

Un jeton d’accès est obtenu en authentifiant l’utilisateur auprès d’un <Tooltip tip="Serveur d’autorisation : serveur centralisé qui contribue à définir les limites de l’accès d’un utilisateur. Par exemple, votre serveur d’autorisation peut contrôler les données, les tâches et les fonctionnalités accessibles à un utilisateur." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Authorization+Server">serveur d’autorisation</Tooltip>, après quoi l’utilisateur peut à son tour autoriser l’application à accéder à l’API en son nom.

<Card title="Qu’est-ce qu’un jeton d’accès ?">
  Un jeton d’accès (aussi appelé `access_token`) est une chaîne opaque représentant une autorisation accordée à l’application. Il peut s’agir d’un identifiant servant à récupérer l’information d’autorisation, ou encore contenir lui-même l’information d’autorisation (par exemple, l’identité de l’utilisateur, les permissions, etc.) d’une manière vérifiable.

  Il est très courant que les jetons d’accès soient mis en œuvre sous forme de [JSON Web Tokens](/docs/fr-ca/secure/tokens/json-web-tokens).

  Pour en savoir plus sur les jetons d’accès Auth0, consultez [Access Token](/docs/fr-ca/secure/tokens/access-tokens).
</Card>

Une API peut appliquer un contrôle granulaire sur les personnes qui peuvent accéder aux différents points de terminaison qu’elle expose. Ces permissions sont exprimées sous forme de portées.

Lorsqu’un utilisateur autorise une application cliente, l’application peut aussi indiquer les permissions dont elle a besoin. L’utilisateur peut alors examiner ces permissions et les accorder. Ces permissions sont ensuite incluses dans le jeton d’accès, dans la revendication `scope`.

Par la suite, lorsque le client transmet le jeton d’accès en effectuant des requêtes vers l’API, l’API peut inspecter la revendication `scope` pour s’assurer que les permissions requises ont bien été accordées afin d’appeler le point de terminaison d’API en question.

<Card title="Que sont les portées ?">
  Chaque jeton d’accès peut inclure une liste des permissions qui ont été accordées au client. Lorsqu’un client s’authentifie auprès d’Auth0, il précise la liste des portées (ou permissions) qu’il demande. Si ces portées sont autorisées, alors le jeton d’accès contiendra une liste des portées autorisées.

  Par exemple, l’API de feuilles de temps peut accepter quatre niveaux d’autorisation différents : la lecture des feuilles de temps (portée `read:timesheets`), la création de feuilles de temps (portée `create:timesheets`), la suppression de feuilles de temps (portée `delete:timesheets`) et l’approbation de feuilles de temps (portée `approve:timesheets`).

  Lorsqu’un client demande à l’API de créer une nouvelle entrée de feuille de temps, le jeton d’accès doit alors contenir la portée `create:timesheets`. De la même façon, pour supprimer des feuilles de temps existantes, le jeton d’accès doit contenir la portée `delete:timesheets`.

  Pour en savoir plus sur les portées, consultez [Scopes](/docs/fr-ca/get-started/apis/scopes).
</Card>

En utilisant le framework d’autorisation <Tooltip tip="OAuth 2.0 : framework d’autorisation qui définit les protocoles et les workflows d’autorisation." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip>, vous pouvez accorder à vos propres applications ou à des applications tierces un accès limité à vos API au nom de l’application elle-même. Avec Auth0, vous pouvez facilement prendre en charge différents flux dans vos propres API sans avoir à vous soucier de la spécification OAuth 2.0/<Tooltip tip="OpenID : norme ouverte d’authentification qui permet aux applications de vérifier l’identité des utilisateurs sans recueillir ni stocker les informations de connexion." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OpenID">OpenID</Tooltip> Connect (OIDC), ni des nombreux autres aspects techniques de l’autorisation d’API.

<Card title="Rôles OAuth">
  Dans tout flux OAuth 2.0, on peut identifier les rôles suivants :

  * **Resource Owner** : l’entité qui peut accorder l’accès à une ressource protégée. Il s’agit généralement de l’utilisateur final.
  * **Resource Server** : le serveur qui héberge les ressources protégées. C’est l’API à laquelle vous voulez accéder.
  * **Client** : une application qui demande l’accès à une ressource protégée pour le compte du Resource Owner.
  * **serveur d’autorisation** : le serveur qui authentifie le Resource Owner et émet des jetons d’accès après avoir obtenu l’autorisation nécessaire. Dans ce cas-ci, il s’agit de l’Authentication API d’Auth0.

  Les [types d’autorisation (ou flux)](/docs/fr-ca/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) déterminent comment ces participants interagissent pour accorder aux applications un accès limité aux API que vous développez. Par conséquent, l’application obtiendra un jeton d’accès qu’elle pourra utiliser pour faire une requête à l’API au nom de l’utilisateur.
</Card>

<div id="implicit-grant">
  ## Octroi implicite
</div>

OAuth 2.0 offre plusieurs **types d’octroi** pour différents cas d’utilisation. Dans ce cas d’utilisation précis, nous voulons accéder à l’API à partir d’une [application côté client](/docs/fr-ca/quickstart/spa).

La SPA utilisera le [flux implicite (octroi implicite)](/docs/fr-ca/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post) pour ce faire.

L’octroi implicite (défini dans la [RFC 6749, section 4.1](https://tools.ietf.org/html/rfc6749#section-4.2)) est semblable à l’octroi utilisé dans le [flux de code d’autorisation](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow), mais la principale différence est que l’application reçoit directement un jeton d’accès, sans avoir besoin d’un `authorization_code`. Cela s’explique par le fait que l’application, qui est généralement une application JavaScript exécutée dans un navigateur, est considérée comme moins fiable qu’une application web exécutée sur le serveur; on ne peut donc pas lui confier le `client_secret` (qui est requis dans l’octroi par code d’autorisation).

Une fois l’utilisateur authentifié, l’application reçoit le <Tooltip tip="ID Token : Information d’identification destinée au client lui-même, plutôt qu’à l’accès à une ressource." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=ID+Token">ID Token</Tooltip> et le jeton d’accès dans le fragment de hachage de l’URI. L’application peut maintenant utiliser l’ID Token pour obtenir des renseignements sur l’utilisateur, et le jeton d’accès pour envoyer une requête à l’API au nom de l’utilisateur.

1. L’application démarre le flux et redirige le navigateur vers Auth0 (plus précisément vers le [point de terminaison /authorize](https://auth0.com/docs/api/authentication#implicit-grant)), afin que l’utilisateur puisse s’authentifier.
2. Auth0 authentifie l’utilisateur. La première fois que l’utilisateur passe par ce flux, si l’application est une application tierce, une page de consentement s’affiche; elle présente les permissions qui seront accordées au client (par exemple, publier des messages, afficher des contacts, etc.).
3. Auth0 redirige l’utilisateur vers l’application avec un jeton d’accès (et, facultativement, un ID Token) dans le fragment de hachage de l’URI. L’application peut maintenant extraire les jetons du fragment de hachage.
4. L’application peut utiliser le jeton d’accès pour envoyer une requête à l’API au nom de l’utilisateur.

<div id="authorization-extension">
  ## Authorization Extension
</div>

L’[Auth0 Authorization Extension](/docs/fr-ca/customize/extensions/authorization-extension) vous permet de configurer des rôles, des groupes et des permissions, puis de les attribuer à des utilisateurs.

* Les permissions sont les actions qu’une personne peut effectuer. Pour répondre aux besoins d’affaires d’ExampleCo, nous configurerons quatre permissions : lire, créer, supprimer et approuver des feuilles de temps.
* Les rôles sont des ensembles de permissions. L’application de feuilles de temps d’ExampleCo sera utilisée par deux types d’utilisateurs (employés et gestionnaires), chacun ayant des permissions différentes; nous configurerons donc deux rôles : employé et gestionnaire.

Comme cela répond à notre cas d’utilisation, nous ne créerons aucun groupe.

L’Authorization Extension créera une [Rule](/docs/fr-ca/customize/rules) qui lira les rôles, les groupes et les permissions attribués à un utilisateur et ajoutera cette information au [profil utilisateur](/docs/fr-ca/customize/rules#rule-syntax) pendant le flux d’authentification. Nous pouvons utiliser cette information pour nous assurer que le jeton d’accès émis à un utilisateur ne contient que les portées autorisées. Nous pourrons ensuite personnaliser notre application, par exemple en désactivant la fonctionnalité Approve Timesheets si l’utilisateur n’a pas la permission requise pour le faire.