Skip to main content
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. 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.

​
OAuth 2.0

En s’appuyant sur le , 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 ou flux d’authentification sans avoir à se soucier de la spécification OAuth 2.0/ Connect (OIDC), ni des nombreux autres aspects techniques liés à l’autorisation des API.

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

​
Client Credentials Grant

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 ) 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 (l’API) pour son propre compte. Dans ce type de situation, où il n’y a aucune interaction utilisateur, le Client Credentials Grant est idéal. Avec le Client Credentials Grant (défini dans la RFC 6749, section 4.4), une application peut demander directement un auprès du en utilisant ses client credentials (un et un ). Au lieu d’identifier un Resource Owner, ce jeton d’accès représente l’application elle-même.
undefined
  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.

​
Authentification et autorisation des API

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.

​
Jetons d’accès et portées

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