Passer au contenu principal
Dans cette section, nous verrons comment nous pouvons mettre en œuvre une API pour notre scénario.
Pour des raisons de simplicité, notre implémentation se concentrera uniquement sur l’authentification et l’autorisation. Comme vous le verrez dans les exemples, l’entrée de la feuille de temps sera codée en dur et l’API ne conservera pas l’entrée de la feuille de temps. Au lieu de cela, elle renverra simplement certaines informations.

​
Définir les points de terminaison de l’API

Nous devons d’abord définir les points de terminaison de notre API.

Qu’est-ce qu’un point de terminaison d’API?

Un point de terminaison d’APIPar exemple, une API de restaurant pourrait avoir des points de terminaison tels que /orders et /customers. Une application qui se connecte à cette API peut effectuer des opérations CRUD (create, read, update, delete) en appelant un point de terminaison d’API à l’aide de la méthode HTTP associée (POST, GET, PUT, PATCH ou DELETE).
Pour cette implémentation, nous ne définirons que deux points de terminaison : un pour récupérer une liste de toutes les feuilles de temps d’un employé, et un autre pour permettre à un employé de créer une nouvelle entrée de feuille de temps. Une requête HTTP GET au point de terminaison /timesheets permettra à un utilisateur de récupérer ses feuilles de temps, et une requête HTTP POST au point de terminaison /timesheets permettra à un utilisateur d’ajouter une nouvelle feuille de temps. Voir l’implémentation dans Node.js

​
Sécuriser les points de terminaison

Lorsqu’une API reçoit une requête avec un jeton d’accès porteur dans l’en-tête, la première chose à faire est de valider le jeton. Cette validation consiste en une série d’étapes, et si l’une de ces étapes échoue, la requête doit être rejetée avec un message d’erreur Missing or invalid token envoyé à l’application appelante. Les validations que l’API doit effectuer sont les suivantes :
  • Vérifier que le jeton est bien formé
  • Vérifier la signature
  • Valider les demandes standard
JWT.io fournit une liste de bibliothèques qui peuvent faire la plupart du travail pour vous : analyser le JWT, vérifier la signature et les demandes.
Une partie du processus de validation consiste également à vérifier les permissions du client, mais nous aborderons cette question séparément dans le prochain paragraphe de ce document. Pour en savoir plus sur la validation des jetons d’accès, consultez Valider les jetons d’accès. Voir l’implémentation dans Node.js

​
Vérifier les permissions du client

Nous avons maintenant vérifié que le jeton JWT est valide. La dernière étape consiste à vérifier que le client dispose des permissions requises pour accéder aux ressources protégées. Pour ce faire, l’API doit vérifier les permissions du jeton JWT décodé en consultant l’objet permissions. Cette demande fait partie de la charge utile et il s’agit d’une liste de chaînes séparées par des espaces. Voir l’implémentation dans Node.js

​
Déterminer l’identité utilisateur

Pour les deux points de terminaison (récupération de la liste des feuilles de temps et ajout d’une nouvelle feuille de temps), nous devrons déterminer l’identité utilisateur. Pour récupérer la liste des feuilles de temps, cela permet de s’assurer que nous renvoyons uniquement les feuilles de temps appartenant à l’utilisateur qui fait la demande, et pour ajouter une nouvelle feuille de temps, cela permet de s’assurer que la feuille de temps est associée à l’utilisateur qui fait la demande. L’une des demandes standard de JWT est la demande sub qui détermine le demandeur qui fait l’objet de la demande. Dans le cas du flux d’autorisation implicite, cette demande contiendra l’identité utilisateur, qui sera l’identifiant unique de l’utilisateur Auth0. Vous pouvez l’utiliser pour associer n’importe quelle information dans des systèmes externes à un utilisateur particulier. Vous pouvez également utiliser une demande personnalisée pour ajouter au jeton d’accès un autre attribut de l’utilisateur, tel que son adresse courriel, et l’utiliser pour identifier l’utilisateur de manière unique. Voir l’implémentation dans Node.js

​
Implémenter l’application mobile

Dans cette section, nous verrons comment implémenter une application mobile pour notre scénario. Voir l’implémentation dans Android.

​
Autoriser l’utilisateur

Pour autoriser l’utilisateur, nous implémenterons le Flux de code d’autorisation avec Proof Key for Code Exchange (PKCE). L’application mobile devrait premièrement envoyer l’utilisateur vers l’URL d’autorisation en plus du code_challenge et de la méthode utilisée pour le générer : La demande GET vers l’URL d’autorisation devrait inclure les valeurs suivantes : Voir l’implémentation dans Android.

​
Obtenir les identifiants

Après une demande réussie à l’URL d’autorisation, vous devriez recevoir la réponse suivante : Ensuite vous pouvez échanger le authorization_code de la réponse pour un jeton d’accès qui peut être utilisé pour appeler votre API. Réalisez une demande POST à l’URL du jeton incluant les données suivantes : La réponse de l’URL du jeton comprendra :
  • access_token: Un jeton d’accès pour l’API, spécifié par l’objet audience.
  • refresh_token: Un jeton d’actualisation ne sera présent que si vous avez inclus la permission offline_access ET activé Autoriser l’accès hors ligne pour votre API dans le Dashboard.
  • id_token : Un jeton d’ID JWT contenant des informations de profil utilisateur.
  • token_type : Un lien contenant le type de jeton, ce sera toujours un jeton du porteur.
  • expires_in : Temps en secondes avant l’expiration du jeton d’accès.
Vous devrez stocker les identifiants ci-dessus dans le stockage local pour pouvoir appeler votre API et récupérer le profil utilisateur. Voir l’implémentation dans Android.

​
Obtenez le profil utilisateur

Pour récupérer le Profil utilisateur, votre application mobile peut décoder le jeton d’ID à l’aide de l’une des bibliothèques JWT. Ceci est réalisé en vérifiant la signature et en vérifiant les demandes du jeton. Une fois le jeton d’ID validé, vous pouvez accéder sa charge utile contenant les informations suivantes sur l’utilisateur :
Voir l’implémentation dans Android.

​
Afficher les éléments de l’interface utilisateur de manière conditionnelle en fonction de la permission

Selon la permission de l’utilisateur visible dans l’objet scope, vous pouvez afficher ou masquer certains éléments de l’interface utilisateur. Pour déterminer la permission accordée à un utilisateur, vous devrez inspecter la permission octroyée quand l’utilisateur a été authentifié. Il s’agira d’un lien contenant toutes les permissions, vous devez donc l’inspecter pour voir s’il contient la permission requise et, sur cette base, prendre la décision d’afficher ou non un élément d’interface utilisateur particulier. Voir l’implémentation dans Android

​
Appeler l’API

Pour accéder aux ressources sécurisées à partir de votre API, le jeton d’accès de l’utilisateur authentifié doit être inclus dans les demandes qui lui sont envoyées. Pour ce faire, il faut envoyer le jeton d’accès dans un en-tête Authorization à l’aide du schéma Bearer. Voir l’implémentation dans Android.

​
Renouveler le jeton

Les applications doivent stocker les jetons d’actualisation en toute sécurité car ils n’expirent pas et permettent à un utilisateur de rester authentifié pratiquement indéfiniment. Si les jetons d’actualisation sont compromis ou ne vous sont plus utiles, vous pouvez les révoquer à l’aide de l’Authentication API.
Pour actualiser votre jeton d’accès, effectuez une demande POST au point de terminaison /oauth/token à l’aide du jeton d’actualisation de votre résultat d’autorisation. Un Jeton d’actualisation ne sera présent que si vous avez inclus la permission offline_access dans la demande d’autorisation précédente et activé Autoriser l’accès hors ligne pour votre API dans le Dashboard. Votre demande devrait comprendre : La réponse comprendra le nouveau jeton d’accès :
Voir l’implémentation dans Android.