Passer au contenu principal
Afin de s’assurer que seuls les utilisateurs et les applications autorisés puissent accéder à l’API Timesheets, ExampleCo a décidé d’utiliser le framework d’autorisation OAuth 2.0. Ce framework offre à l’entreprise la souplesse recherchée, puisque les différents modes d’octroi lui permettent d’autoriser facilement les divers types d’applications qui doivent communiquer avec l’API Timesheets.

​
Authentification et autorisation des API

Une API permet d’exposer les fonctionnalités de votre application à d’autres applications. Une application peut envoyer une requête à un point de terminaison d’une API et recevoir des informations en réponse. Un point de terminaison d’API peut être sécurisé ou non. Dans notre cas, puisque les feuilles de temps sont des renseignements sensibles qui ont une incidence sur les évaluations et les paiements, il est important de s’assurer que seuls les utilisateurs et les applications autorisés peuvent appeler les points de terminaison de notre API. Lorsqu’une application cliente veut accéder à des points de terminaison protégés d’une API, elle doit présenter un comme preuve qu’elle possède les autorisations requises pour appeler ce point de terminaison. Un Jeton d’accès est obtenu en authentifiant l’utilisateur auprès d’un , après quoi l’utilisateur peut autoriser l’application à accéder à l’API en son nom.

Qu’est-ce qu’un jeton d’accès ?

Un jeton d’accès (aussi appelé access_token) est une chaîne opaque qui représente une autorisation accordée à l’application. Il peut s’agir d’un identifiant utilisé pour récupérer les renseignements d’autorisation, ou contenir lui-même ces renseignements (par exemple, l’identité de l’utilisateur, les autorisations, etc.) de manière vérifiable.Il est très courant que les jetons d’accès soient implémentés sous forme de JSON Web Tokens.Pour en savoir plus sur les jetons d’accès Auth0, consultez Access Token.
Une API peut appliquer un contrôle précis sur les personnes pouvant accéder aux différents points de terminaison qu’elle expose. Ces autorisations sont exprimées sous forme de scopes. Lorsqu’un utilisateur autorise une application cliente, l’application peut aussi indiquer les autorisations dont elle a besoin. L’utilisateur peut alors examiner et accorder ces autorisations. Ces autorisations sont ensuite incluses dans le jeton d’accès dans la revendication scope. Par la suite, lorsque l’application cliente transmet le jeton d’accès dans ses requêtes à l’API, l’API peut inspecter la revendication scope pour s’assurer que les autorisations requises ont bien été accordées afin d’appeler le point de terminaison d’API en question.

Que sont les scopes ?

Chaque jeton d’accès peut inclure une liste des autorisations qui ont été accordées à l’application cliente. Lorsqu’une application cliente s’authentifie auprès d’Auth0, elle précise la liste des scopes (ou autorisations) qu’elle demande. Si ces scopes sont autorisés, le jeton d’accès contiendra une liste des scopes autorisés.Par exemple, l’API des feuilles de temps 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).Lorsqu’une application cliente demande à l’API de créer une nouvelle entrée de feuille de temps, le jeton d’accès doit contenir le scope create:timesheets. De même, pour supprimer des feuilles de temps existantes, le jeton d’accès doit contenir le scope delete:timesheets.Pour en savoir plus sur les scopes, consultez Scopes.
En utilisant le cadre d’autorisation , vous pouvez accorder à vos propres applications ou à des applications tierces un accès limité à vos API au nom de l’application elle-même. Avec Auth0, vous pouvez facilement prendre en charge différents flux dans vos propres API sans avoir à vous soucier de la spécification OAuth 2.0/ Connect (OIDC), ni des nombreux autres aspects techniques de l’autorisation des API.

Rôles OAuth

Dans tout flux OAuth 2.0, on peut distinguer 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. Il s’agit de l’API à laquelle vous souhaitez 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, il s’agit de l’API d’authentification d’Auth0.
Les types d’octroi (ou flux) déterminent comment ces participants interagissent pour accorder aux applications un accès limité aux API que vous créez. L’application obtient ainsi un jeton d’accès qui peut être utilisé pour appeler l’API au nom de l’utilisateur.

​
Clé de preuve pour l’échange de code (PKCE)

OAuth 2 offre plusieurs types d’octroi pour différents cas d’utilisation. Dans ce cas précis, nous voulons accéder à l’API à partir d’une application mobile, qui utilisera le flux du code d’autorisation avec clé de preuve pour l’échange de code (PKCE) pour ce faire. Le flux du code d’autorisation présente certains problèmes de sécurité lorsqu’il est mis en œuvre dans des applications natives. Par exemple, un attaquant malveillant peut intercepter le authorization_code renvoyé par Auth0 et l’échanger contre un Jeton d’accès (et éventuellement un Jeton d’actualisation). La clé de preuve pour l’échange de code (PKCE) (définie dans la RFC 7636) est une technique utilisée pour atténuer cette attaque par interception du code d’autorisation. Avec PKCE, l’application crée, pour chaque demande d’autorisation, une clé aléatoire cryptographiquement sécurisée appelée code_verifier et sa valeur transformée appelée code_challenge, qui est envoyée à Auth0 pour obtenir le authorization_code. Lorsque l’application reçoit le authorization_code, elle envoie le code et le code_verifier au d’Auth0 pour les échanger contre les jetons demandés.
Diagramme - Microsite - Code d’autorisation avec PKCE
  1. L’application native lance le flux et redirige l’utilisateur vers Auth0 (plus précisément vers le point de terminaison /authorize), en envoyant les paramètres code_challenge et code_challenge_method.
  2. Auth0 redirige l’utilisateur vers l’application native avec un authorization_code dans la chaîne de requête.
  3. L’application native envoie le authorization_code et le code_verifier, ainsi que le redirect_uri et le client_id, à Auth0. Cela se fait à l’aide du point de terminaison /oauth/token.
  4. Auth0 valide ces renseignements et renvoie un Jeton d’accès (et, facultativement, un Jeton d’actualisation).
  5. L’application native peut utiliser le Jeton d’accès pour appeler l’API au nom de l’utilisateur.
Si la rotation des Jetons d’actualisation est activée, un nouveau Jeton d’actualisation est généré à chaque demande et émis avec le Jeton d’accès. Lorsqu’un Jeton d’actualisation est échangé, le Jeton d’actualisation précédent est invalidé, mais les renseignements sur cette relation sont conservés par le serveur d’autorisation.

​
Extension d’autorisation

L’extension d’autorisation Auth0 vous permet de gérer l’autorisation dans votre application en attribuant des rôles, des groupes et des autorisations aux utilisateurs. L’extension d’autorisation crée une Rule qui enrichit le profil utilisateur pendant le flux d’authentification avec les rôles, les groupes et les autorisations attribués à l’utilisateur. Vous pouvez ensuite utiliser ces renseignements pour vous assurer que le Jeton d’accès émis à un utilisateur ne contient que les scopes autorisés selon les autorisations définies dans l’extension d’autorisation. TUTORIEL PRÉCÉDENT Introduction TUTORIEL SUIVANT 2. Configuration d’Auth0