> ## 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 des solutions pour le scénario d’architecture serveur + API

# Aperçu de la solution (applications serveur + 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 grants lui permettent d’autoriser facilement les divers types d’applications qui doivent communiquer avec la Timesheets API.

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

En s’appuyant sur le <Tooltip tip="OAuth 2.0 : cadre 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">cadre d’autorisation OAuth 2.0</Tooltip>, l’application Web classique d’ExampleCo et l’application tierce destinée aux sous-traitants externes peuvent avoir un accès limité à l’API Timesheets. Avec Auth0, ExampleCo peut facilement prendre en charge différents [types d’octroi](/docs/fr-ca/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) ou flux d’authentification sans avoir à se 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 renseignements de connexion." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OpenID">OpenID</Tooltip> Connect (OIDC), ni des nombreux autres aspects techniques liés à l’autorisation des 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 au nom 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 appropriée. Dans ce cas-ci, il s’agit de l’Authentication API d’Auth0.

  Les [types d’octroi (ou flux)](/docs/fr-ca/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) déterminent comment ces acteurs interagissent afin d’accorder aux applications un accès limité aux API que vous créez. L’application obtiendra ainsi 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 (ou <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="/docs/fr-ca/glossary?term=resource+owner">resource owner</Tooltip>) pour accorder au cron job les permissions nécessaires pour accéder à l’API.

Le cron job n’effectue pas non plus les appels d’API au nom d’un utilisateur. L’application (le cron job) utilise plutôt l’autorisation machine-to-machine et effectue des appels au <Tooltip tip="Resource Server : serveur qui héberge des ressources protégées. Les resource servers acceptent les requêtes de ressources protégées et y répondent." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Resource+Server">Resource Server</Tooltip> (l’API) pour son propre compte.

Dans ce type de situation, où il n’y a aucune interaction utilisateur, le [Client Credentials Grant](/docs/fr-ca/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="Jeton d’accès : 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="/docs/fr-ca/glossary?term=access+token">jeton d’accès</Tooltip> auprès du <Tooltip tip="Jeton d’accès : 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="/docs/fr-ca/glossary?term=Authorization+Server">serveur d’autorisation</Tooltip> en utilisant ses client credentials (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 auxquelles un utilisateur a accès." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Client+ID">Client ID</Tooltip> et un <Tooltip tip="Client Secret : Secret utilisé par un client (application) pour s’authentifier auprès du serveur d’autorisation; il ne devrait être connu que du client et du serveur d’autorisation et doit être suffisamment aléatoire pour ne pas pouvoir être deviné." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Client+Secret">Client Secret</Tooltip>). Au lieu d’identifier un Resource Owner, ce jeton d’accès représente 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 Client ID et de son Client Secret.
2. Le serveur d’autorisation valide ces informations et renvoie un jeton d’accès.
3. L’application peut utiliser le jeton d’accès pour appeler le Resource Server en son propre nom.

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

Une API permet d’exposer les fonctionnalités de votre application à d’autres applications. D’autres applications peuvent envoyer une requête à un endpoint d’API et recevoir une réponse. De la même manière, l’application externe qu’utilisent les sous-traitants d’ExampleCo peut communiquer avec la Timesheets API ainsi qu’avec l’application Web classique qu’ExampleCo a créée pour ses employés internes.

Comme la Timesheets API traite des renseignements sensibles (comme des PII et des renseignements financiers), ExampleCo doit s’assurer que seuls les utilisateurs et les applications autorisés peuvent appeler ses endpoints.

<div id="access-tokens-and-scopes">
  ### Jetons d’accès et portées
</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 permissions requises.

Un jeton d’accès est une chaîne opaque qui représente une autorisation accordée à l’application. Il est obtenu 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](/docs/fr-ca/secure/tokens/access-tokens).

Une API comme Timesheets 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.

Lorsque l’application Web classique de 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 portées demandées dont l’application a besoin. Si ces portées sont autorisées, le jeton d’accès contiendra alors la liste des portées autorisées accordées à l’application.

La Regular Web App ou l’application tierce inclut le jeton d’accès du serveur d’autorisation lorsqu’elle envoie des requêtes à Timesheets API, et Timesheets API inspecte le claim `scope` pour s’assurer que les permissions requises ont bien été accordées avant d’autoriser l’appel au point de terminaison en question.

Par exemple, l’API de feuilles de temps peut accepter quatre niveaux d’autorisation différents : lire des feuilles de temps (portée `read:timesheets`), créer des feuilles de temps (portée `create:timesheets`), supprimer des feuilles de temps (portée `delete:timesheets`) et approuver des feuilles de temps (portée `approve:timesheets`).

Pour plus d’informations sur les portées, consultez [Portées](/docs/fr-ca/get-started/apis/scopes).

Lorsque la Regular Web App envoie une requête à Timesheets API pour créer une nouvelle entrée de feuille de temps, le jeton d’accès doit contenir la portée `create:timesheets`, sans quoi la requête sera refusée. De même, pour supprimer des feuilles de temps existantes, le jeton d’accès doit contenir la portée `delete:timesheets`.

Pour en savoir plus, consultez [Portées](/docs/fr-ca/get-started/apis/scopes).