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

> Vue d’ensemble de la solution pour le scénario d’architecture serveur + API

# Vue d’ensemble de la solution (applications serveur + API)

Afin de veiller à ce que seuls les utilisateurs et les applications autorisés aient accès à l’API Timesheets, 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 octrois lui permettent d’autoriser facilement les divers types d’applications qui doivent communiquer avec l’API Timesheets.

<div id="oauth-20">
  ## OAuth 2.0
</div>

En utilisant le cadre d’autorisation <Tooltip tip="OAuth 2.0 : cadre d’autorisation qui définit des protocoles et des flux d’autorisation." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip>, l’Application Web régulière d’ExampleCo et l’application tierce destinée aux entrepreneurs externes peuvent avoir un accès limité à l’API Timesheets. Grâce à Auth0, ExampleCo peut facilement prendre en charge différents [types d’octroi](/fr-CA/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) ou flux d’authentification sans se préoccuper 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 renseignements de connexion." cta="Voir le glossaire" href="/fr-CA/docs/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, nous pouvons identifier les rôles suivants :

  * **Propriétaire de la ressource** : l’entité qui peut accorder l’accès à une ressource protégée. Il s’agit généralement de l’utilisateur final.
  * **Serveur de ressources** : le serveur qui héberge les ressources protégées. C’est l’API à laquelle vous voulez accéder.
  * **Application** : une application qui demande l’accès à une ressource protégée au nom du propriétaire de la ressource.
  * **Serveur d’autorisation** : le serveur qui authentifie le propriétaire de la ressource et émet des Jetons d’accès après avoir obtenu l’autorisation appropriée. Dans ce cas-ci, il s’agit de l’Authentication API d’Auth0.

  Les [types d’octroi (ou flux)](/fr-CA/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) déterminent comment ces participants interagissent afin d’accorder aux applications un accès limité aux API que vous créez. Par conséquent, l’application obtiendra un jeton d’accès qui pourra être utilisé pour appeler l’API au nom de l’utilisateur.
</Card>

<div id="client-credentials-grant">
  ### Client Credentials Grant
</div>

OAuth 2 offre plusieurs types d’octroi pour différents cas d’utilisation. Dans ce cas précis, où une tâche cron téléverse des feuilles de temps au moyen d’une API, il n’y a aucun utilisateur interactif (ni <Tooltip tip="Resource Owner : entité (comme un utilisateur ou une application) capable d’accorder l’accès à une ressource protégée." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=resource+owner">propriétaire de la ressource</Tooltip>) pour accorder au job cron les autorisations nécessaires afin d’accéder à l’API.

La tâche cron n’effectue pas non plus les appels d’API au nom d’un utilisateur. L’application (la tâche cron) utilise plutôt l’autorisation Machine-to-Machine et effectue des appels au <Tooltip tip="Resource Server : serveur hébergeant des ressources protégées. Les serveurs de ressources acceptent les demandes de ressources protégées et y répondent." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Resource+Server">serveur de ressources</Tooltip> (l’API) pour son propre compte.

Dans ce type de situation, où aucune interaction utilisateur n’est requise, le [Client Credentials Grant](/fr-CA/docs/get-started/authentication-and-authorization-flow/client-credentials-flow) est idéal. Avec le Client Credentials Grant (défini dans la [RFC 6749, section 4.4](https://tools.ietf.org/html/rfc6749#section-4.4)), une application peut demander directement un <Tooltip tip="Access Token : information d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisée pour accéder à une API." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=access+token">jeton d’accès</Tooltip> au <Tooltip tip="Access Token : information d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisée pour accéder à une API." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Authorization+Server">serveur d’autorisation</Tooltip> en utilisant les identifiants de l’application (un <Tooltip tip="Authorization Server : 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="/fr-CA/docs/glossary?term=Client+ID">ID client</Tooltip> et un <Tooltip tip="Client Secret : secret utilisé par une application pour s’authentifier auprès du serveur d’autorisation; il doit être connu uniquement de l’application et du serveur d’autorisation, et être suffisamment aléatoire pour ne pas pouvoir être deviné." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Client+Secret">Secret client</Tooltip>). Au lieu d’identifier un Resource Owner, ce jeton représentera l’application elle-même.

<Frame>
  <img src="https://mintcdn.com/translations/MV7tE-x71x8RWRES/docs/images/cdy7uua7fh8z/5CfNEkbyG1ZC5BqHwi9gEs/309babf8329b165f1241f4cbc8e002ba/client-credentials-grant.png?fit=max&auto=format&n=MV7tE-x71x8RWRES&q=85&s=94755d8d68bfaf27437b43220939ef8c" alt="undefined" width="750" height="286" data-path="docs/images/cdy7uua7fh8z/5CfNEkbyG1ZC5BqHwi9gEs/309babf8329b165f1241f4cbc8e002ba/client-credentials-grant.png" />
</Frame>

1. L’application s’authentifie auprès du serveur d’autorisation à l’aide de son ID client et de son Secret client.
2. Le serveur d’autorisation valide ces renseignements et renvoie un jeton d’accès.
3. L’application peut utiliser le jeton d’accès pour appeler le serveur de ressources pour son propre compte.

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

Une API est un moyen d’exposer les fonctionnalités de votre application à d’autres applications. D’autres applications peuvent envoyer une requête à un point de terminaison d’API et recevoir une réponse. De même, l’application externe utilisée par les sous-traitants d’ExampleCo peut communiquer avec l’API Timesheet ainsi qu’avec l’Application Web régulière qu’ExampleCo a créée pour ses employés internes.

Comme l’API Timesheets traite des renseignements sensibles (comme des RPI et des renseignements financiers), ExampleCo doit s’assurer que seuls les utilisateurs et les applications autorisés peuvent appeler ses points de terminaison.

<div id="access-tokens-and-scopes">
  ### Jetons d’accès et scopes
</div>

Les API peuvent être sécurisées ou non. Lorsqu’une application veut accéder à des points de terminaison protégés d’une API, elle doit fournir un jeton d’accès (aussi appelé `access_token`) comme preuve qu’elle possède les autorisations requises.

Un jeton d’accès est une chaîne opaque représentant une autorisation accordée à l’application, obtenue en authentifiant l’utilisateur auprès d’un serveur d’autorisation. L’utilisateur peut ensuite autoriser l’application à accéder à l’API en son nom. Pour en savoir plus, consultez [Jetons d’accès](/fr-CA/docs/secure/tokens/access-tokens).

Une API comme la Timesheets API peut appliquer un contrôle précis sur l’accès aux différents points de terminaison qu’elle expose. Ces autorisations sont exprimées sous forme de scopes.

Lorsque l’Application Web régulière d’ExampleCo ou l’application tierce s’authentifie auprès d’Auth0 pour obtenir un jeton d’accès, la requête d’authentification inclut la liste des scopes demandés dont l’application a besoin. Si ces scopes sont autorisés, le jeton d’accès contiendra alors la liste des scopes accordés à l’application.

L’Application Web régulière ou l’application tierce inclut le jeton d’accès provenant du serveur d’autorisation lorsqu’elle envoie des requêtes à la Timesheets API, et la Timesheets API examine la revendication `scope` pour s’assurer que les autorisations requises ont été accordées afin d’appeler le point de terminaison en question.

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

Pour plus d’informations sur les scopes, consultez [Scopes](/fr-CA/docs/get-started/apis/scopes).

Lorsque l’Application Web régulière envoie une requête à la Timesheets API pour créer une nouvelle entrée de feuille de temps, le jeton d’accès doit contenir le scope `create:timesheets`, sinon la requête sera refusée. De la même façon, pour supprimer des feuilles de temps existantes, le jeton d’accès doit contenir le scope `delete:timesheets`.

Pour en savoir plus, consultez [Scopes](/fr-CA/docs/get-started/apis/scopes).