Passer au contenu principal
Afin de s’assurer que seuls les utilisateurs et applications autorisés ont accès à l’API des feuilles de temps, ExampleCo a décidé d’utiliser le cadre d’applications Authorization OAuth 2.0. Le cadre d’applications offre la flexibilité que l’entreprise souhaite puisque les différentes autorisations peuvent lui permettre d’autoriser facilement les différents types d’applications qui ont besoin de communiquer avec l’API des feuilles de temps.

​
OAuth 2.0

En utilisant le cadre d’applications Authorization  2.0, l’application Web standard d’ExampleCo et l’application tierce pour les sous-traitants externes peuvent avoir un accès limité à l’API des feuilles de temps. En utilisant Auth0, ExampleCo peut facilement prendre en charge différents types d’autorisation ou flux d’authentification sans se soucier de la spécification OAuth 2.0/ Connect (OIDC) ou 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 :
  • Resource Owner (Propriétaire de ressource) : l’entité qui peut donner accès à la ressource protégée. Il s’agit habituellement de l’utilisateur final.
  • Resource Server (Serveur de ressources) : serveur hébergeant les ressources protégées. Il s’agit de l’API à laquelle vous souhaitez accéder.
  • Client : une application demandant l’accès à une ressource protégée au nom du propriétaire de ressource.
  • Authorization Server (Serveur d’autorisation) : le serveur qui authentifie le propriétaire de ressource, et émet les jetons d’accès afin de fournir l’autorisation adéquate. Dans ce cas, l’Authentication API Auth0.
Les types d’autorisations (ou flux) determinent comment ces participants interagiront pour autoriser un accès limité des applications client aux API que vous créez. En conséquence, l’application obtiendra un jeton d’accès qui peut être utilisé pour appeler l’API au nom de l’utilisateur.

​
Autorisation des identifiants client

OAuth 2.0 fournit plusieurs types d’autorisation pour différents cas d’utilisation. Dans ce cas d’utilisation particulier où une tâche Cron téléverse des feuilles de temps par l’intermédiaire d’une API, il n’y a pas d’utilisateur interactif (ou de propriétaire de ressource) qui accorde des autorisations d’accès à l’API à la tâche Cron. La tâche Cron n’effectue pas non plus les appels d’API au nom d’un utilisateur. Au lieu de cela, l’application (la tâche Cron) utilise l’autorisation de communication entre machines pour appeler le serveur de ressources (l’API) en son propre nom. Pour des situations comme celle-ci où il n’y a aucune interaction de l’utilisateur, l’autorisation des identifiants client est idéale. Avec l’autorisation des identifiants client (définie dans la RFC 6749, section 4.4), une application peut demander directement un jeton d’accès au serveur d’autorisation en utilisant ses identifiants client (un ID client et un secret client). Au lieu d’identifier un propriétaire de ressource, 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 informations et renvoie un jeton d’accès.
  3. L’application peut utiliser le jeton d’accès pour appeler le serveur de ressources en son nom.

​
Authentification et autorisation de l’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 de l’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 des feuilles de temps ainsi qu’avec l’application Web standard conçue par ExampleCo pour les employés internes. Étant donné que l’API des feuilles de temps traite les informations sensibles (telles que les informations personnelles identifiables et les informations financières), ExampleCo doit s’assurer que seuls les utilisateurs et les applications autorisés peuvent appeler ses points de terminaison.

​
Jetons d’accès et permissions

Les API peuvent être sécurisées ou non. Lorsqu’une application souhaite accéder à des points de terminaison protégés sur une API, elle doit fournir un jeton d’accès (également appelé access_token) comme preuve qu’elle dispose des autorisations requises. Un jeton d’accès est une chaîne opaque représentant une autorisation délivrée à l’application et obtenue en authentifiant l’utilisateur auprès d’un serveur d’autorisation. L’utilisateur peut alors, à son tour, autoriser l’application à accéder à l’API en son nom. Pour en savoir plus, veuillez consulter la section Jetons d’accès. Une API comme l’API des feuilles de temps peut appliquer un contrôle précis sur qui peut accéder aux différents points de terminaison exposés par l’API. Ces autorisations sont exprimées sous la forme de permissions. Lorsque l’application Web standard d’ExampleCo ou l’application tierce s’authentifie auprès de Auth0 pour obtenir un jeton d’accès, la demande d’authentification inclut la liste des permissions demandées dont l’application a besoin. Si ces permissions sont autorisées, le jeton d’accès contiendra la liste des permissions accordées à l’application. L’application Web standard ou tierce inclut le jeton d’accès du serveur d’autorisation lors de l’envoi de requêtes à l’API des feuilles de temps, et l’API des feuilles de temps inspecte la demande de permission pour s’assurer que les autorisations requises ont été accordées pour appeler le point de terminaison particulier. Par exemple, l’API des feuilles de temps peut accepter quatre niveaux d’autorisation différents : lecture des feuilles de temps (permission read:timesheets), création des feuilles de temps (permission create:timesheets), suppression des feuilles de temps (permission delete:timesheets) et approbation des feuilles de temps (permission approve:timesheets). Pour en savoir plus sur les permissions, consultez la section Permissions. Lorsque l’application Web standard envoie une demande à l’API des feuilles de temps pour créer une nouvelle entrée de feuille de temps, le jeton d’accès doit contenir la permission create:timesheets, sinon la demande sera refusée. D’une manière similaire, afin de supprimer des feuilles de temps existantes, le jeton d’accès doit contenir la permission delete:timesheets. Pour en savoir plus, lisez la section Permissions.