Skip to main content
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 grants lui permettent d’autoriser facilement les divers types d’applications qui doivent communiquer avec l’API Timesheets.

​
Authentification et autorisation de l’API

Une API permet d’exposer les fonctionnalités de votre application à d’autres applications. Une application peut faire une requête en envoyant un message à 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 veiller à ce que seuls les utilisateurs et les applications autorisés puissent faire des requêtes aux points de terminaison de notre API. Lorsqu’une application cliente veut accéder à des points de terminaison protégés sur une API, elle doit présenter un comme preuve qu’elle possède les permissions requises pour faire la requête au point de terminaison. Un jeton d’accès est obtenu en authentifiant l’utilisateur auprès d’un , puis l’utilisateur peut, à son tour, 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 représentant une autorisation émise à l’application. Il peut s’agir d’un identifiant utilisé pour récupérer les informations d’autorisation, ou encore contenir lui-même les informations d’autorisation (par exemple, l’identité de l’utilisateur, les permissions, etc.) d’une manière vérifiable.Il est assez courant que les jetons d’accès soient mis en œuvre 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 qui peuvent accéder aux différents points de terminaison qu’elle expose. Ces permissions sont exprimées sous forme de portées. Lorsqu’un utilisateur autorise une application cliente, l’application peut aussi indiquer les permissions dont elle a besoin. L’utilisateur peut alors les examiner et les accorder. Ces permissions sont ensuite incluses dans le jeton d’accès dans le claim scope. Par la suite, lorsque le client transmet le jeton d’accès en faisant des requêtes à l’API, l’API peut inspecter le claim scope pour s’assurer que les permissions requises ont bien été accordées pour appeler le point de terminaison d’API en question.

Que sont les portées ?

Chaque jeton d’accès peut inclure une liste des permissions accordées au client. Lorsqu’un client s’authentifie auprès d’Auth0, il précise la liste des portées (ou permissions) qu’il demande. Si ces portées sont autorisées, le jeton d’accès contiendra alors une liste de portées autorisées.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).Lorsqu’un client demande à l’API de créer une nouvelle entrée de feuille de temps, le jeton d’accès doit alors contenir la portée create:timesheets. De la même façon, pour supprimer des feuilles de temps existantes, le jeton d’accès doit contenir la portée delete:timesheets.Pour en savoir plus sur les portées, consultez Scopes.
En utilisant le framework 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 d’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, il s’agit de l’Authentication API d’Auth0.
Les types de grants (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 faire une requête à 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 depuis une application mobile, qui utilisera le flux d’autorisation avec code et clé de preuve pour l’échange de code (PKCE) pour le faire. Le flux d’autorisation avec code 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 ce type d’attaque par interception du code d’autorisation. Avec PKCE, l’application crée, pour chaque requête d’autorisation, une clé aléatoire générée de façon cryptographiquement sûre 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.
Schéma - 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 informations 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 requête 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 l’information sur cette relation est conservée par le serveur d’autorisation.

​
Authorization Extension

L’Auth0 Authorization Extension vous permet de gérer l’autorisation dans votre application en attribuant des Roles, des Groupes et des Permissions aux utilisateurs. L’Authorization Extension crée une Rule qui enrichit le profil utilisateur pendant le flux d’authentification avec les Roles, Groupes et Permissions 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 portées autorisées selon les permissions définies dans l’Authorization Extension. TUTORIEL PRÉCÉDENT Introduction TUTORIEL SUIVANT 2. Configuration d’Auth0