Passer au contenu principal
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. 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.

​
OAuth 2.0

En utilisant le cadre d’autorisation , 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 ou flux d’authentification sans se préoccuper de la spécification OAuth 2.0/ Connect (OIDC), ni des nombreux autres aspects techniques de l’autorisation d’API.

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

​
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 (ni ) 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 (l’API) pour son propre compte. Dans ce type de situation, où aucune interaction utilisateur n’est requise, 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 au en utilisant les identifiants de l’application (un et un ). Au lieu d’identifier un Resource Owner, ce jeton représentera l’application elle-même.
undefined
  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.

​
Authentification et autorisation des API

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.

​
Jetons d’accès et scopes

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