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).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’erreurMissing 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.
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.jsDé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 demandesub 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 ducode_challenge et de la méthode utilisée pour le générer :
GET vers l’URL d’autorisation devrait inclure les valeurs suivantes :
| Paramètre | Description |
|---|---|
| client_id | La valeur de votre ID client Auth0. Vous pouvez la récupérer dans les paramètres de votre application, dans [Auth0 Dashboard] (https://manage.auth0.com/#/applications). |
| audience | La valeur de votre identifiant d’API. Vous pouvez la récupérer dans les paramètres de votre API, dans Auth0 Dashboard. |
| scope | Les permissions qui déterminent les demandes à retourner dans le jeton d’ID et le jeton d’accès. Par exemple, une permission openid retournera un jeton d’ID dans la réponse. Dans notre exemple d’application mobile, nous utilisons les permissions suivantes : create:timesheets read:timesheets openid profile email offline_access. Ces permissions permettent à l’application mobile d’appeler l’API, d’obtenir une valeur Jeton d’actualisation et de retourner les demandes name, picture, et email de l’utilisateur dans le jeton d’ID. |
| response_type | Indique le flux d’authentification à utiliser. Pour une application mobile utilisant PKCE, il devrait être défini sur code. |
| code_challenge | Le défi-réponse de code généré par le vérificateur de code. Vous trouverez des instructions sur la génération d’un défi-réponse de code ici. |
| code_challenge_method | Méthode utilisée pour générer le défi-réponse. Auth0 prend en charge seulement S256. |
| redirect_uri | L’URL vers lequel Auth0 redirigera le navigateur une fois la permission accordée par l’utilisateur. Le code d’autorisation sera indiqué dans le paramètre d’URL du code. Cette URL doit être définie en tant qu’URL de rappel valide dans vos paramètres de l’application. |
Obtenir les identifiants
Après une demande réussie à l’URL d’autorisation, vous devriez recevoir la réponse suivante :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 :
| Paramètre | Description |
|---|---|
| grant_type | Ce paramètre doit être défini sur authorization_code. |
| client_id | La valeur de votre ID client Auth0. Vous pouvez le récupérer dans les paramètres de votre application sur le Auth0 Dashboard. |
| code_verifier | Clé cryptographiquement aléatoire utilisée pour générer le code_challenge transmis à authorization URL (/authorize). |
| code | Le authorization_code reçu de l’appel d’autorisation précédent. |
| redirect_uri | L’URL doit correspondre au redirect_uri de la section précédente à /authorize. |
- 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_accessET 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.
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 :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’objetscope, 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êteAuthorization à 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.
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 :
| Paramètre | Description |
|---|---|
| grant_type | Doit être réglé sur refresh_token. |
| client_id | La valeur de l’ID client Auth0. Vous pouvez l’obtenir dans les paramètres de votre application, dans Auth0 Dashboard. |
| refresh_token | Le jeton d’actualisation à utiliser, à partir du résultat de l’authentification précédente. |