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 2 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 dansNode.js.

​
Sécuriser les points de terminaison

Lorsqu’une API reçoit une requête avec un jeton d’accès du 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 de l’application (scopes), 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 dansNode.js.

​
Vérifier les permissions de l’application

Nous avons maintenant vérifié que le jeton JWT est valide. La dernière étape consiste à vérifier que l’application 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 dansNode.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 dansNode.js.

​
Mettre en œuvre la SPA

Dans cette section, nous verrons comment mettre en œuvre une SPA pour notre scénario.

​
Autoriser l’utilisateur

Pour autoriser l’utilisateur, nous utiliserons la bibliothèque auth0.js. Vous pouvez initialiser une nouvelle instance de l’application Auth0 comme suit : 
var auth0 = new auth0.WebAuth({
  clientID: '{yourClientId}',
  domain: '{yourDomain}',
  responseType: 'token id_token',
  audience: 'YOUR_API_IDENTIFIER',
  redirectUri: '{https://yourApp/callback}',
  scope: 'openid profile read:timesheets create:timesheets'
});
Vous devez transmettre les valeurs de configuration suivantes :
  • clientID : La valeur de votre ID client Auth0. Vous pouvez la récupérer à partir des Paramètres de votre application dans le Dashboard.
  • Domaine  : La valeur de votre domaine Auth0. Vous pouvez la récupérer à partir des Paramètres de votre application dans le Dashboard.
  • responseType : Indique le flux d’authentification à utiliser. Pour une SPA qui utilise le Flux implicite, cette valeur doit être définie sur token ID_token. La partie token déclenche le renvoi par le flux d’un jeton d’accès dans le fragment URL, tandis que la partie id_token déclenche également le renvoi par le flux d’un jeton d’ID.
  •  : Valeur de l’identifiant de votre API. Vous pouvez la récupérer à partir des Paramètres de votre API dans le Tableau de bord.
  • redirectUri : L’URL vers laquelle Auth0 doit rediriger l’utilisateur une fois celui-ci authentifié.
  • scope : Les permissions qui déterminent les informations à renvoyer dans le jeton d’ID et dans le jeton d’accès. Une permission du openid profile (profil ) renvoie toutes les informations du profil utilisateur dans le jeton d’ID. Vous devez également demander les permissions requises pour appeler l’API, dans ce cas les permissions read:timesheets create:timesheets. Cela garantira que le jeton d’accès possède ces permissions.
Pour lancer le flux d’authentification, vous pouvez appeler la méthode authorise() : 
auth0.authorize();
Après l’authentification, Auth0 redirigera l’utilisateur vers l’URL redirectUri que vous avez spécifiée lors de la configuration de la nouvelle instance de l’application Auth0. À ce stade, vous devrez appeler la méthode parseHash() qui analyse un fragment de hachage URL pour extraire le résultat d’une réponse d’authentification Auth0. Le contenu de l’objet authResult renvoyé par la méthode parseHash dépend des paramètres d’authentification utilisés. Il peut comprendre les éléments suivants :
  • idToken : Un jeton d’ID JWT contenant des informations de profil utilisateur
  • accessToken : Un jeton d’accès pour l’API, spécifié par l’objet audience.
  • expiresIn : Chaîne contenant le délai d’expiration (en secondes) du jeton d’accès.
Déterminez le meilleur emplacement où stocker les jetons. Si votre application à page unique dispose d’un serveur dorsal, les jetons doivent être gérés côté serveur à l’aide du flux de code d’autorisation ou du Flux de code d’autorisation avec Proof Key for Code Exchange (PKCE). Si vous avez une application à page unique (SPA) sans serveur dorsal correspondant, votre SPA devrait demander de nouveaux jetons au moment de la connexion et les stocker en mémoire sans aucune persistance. Pour effectuer des appels d’API, votre SPA utilisera alors la copie du jeton en mémoire. Pour voir un exemple de gestion des sessions dans les SPA, consultez la sectionGérer les jetons d’authentification du JavaScriptGuide de démarrage rapide d’une application à page unique. Voir la mise en œuvre dansAngular 2.

​
Obtenez le profil utilisateur

Extraire des informations du jeton

Cette section démontre comment récupérer les informations de l’utilisateur en utilisant le jeton d’accès et le point de terminaison /userinfo. Pour éviter cet appel d’API, vous pouvez simplement décoder le jeton d’ID  en utilisant une bibliothèque (assurez-vous de la valider d’abord). Si vous avez besoin de davantage d’informations utilisateur, envisagez d’utiliser  notre Management API à partir de votre système dorsal.
La méthode client.userInfo peut être appelée en transmettant le jeton authResult.accessToken retourné afin de récupérer les informations du profil de l’utilisateur. Elle fera une requête au point de terminaison /userinfo et retournera l’objet user, qui contient les informations de l’utilisateur, comme dans l’exemple ci-dessous : 
{
    "email_verified": "false",
    "email": "test@example.com",
    "clientID": "AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH",
    "updated_at": "2017-02-07T20:50:33.563Z",
    "name": "tester9@example.com",
    "picture": "https://gravatar.com/avatar/example.png",
    "user_id": "auth0|123456789012345678901234",
    "nickname": "tester9",
    "created_at": "2017-01-20T20:06:05.008Z",
    "sub": "auth0|123456789012345678901234"
}
Vous pouvez accéder à l’une de ces propriétés dans la fonction de rappel passée lors de l’appel de la fonction userInfo : 
const accessToken = authResult.accessToken;

auth0.client.userInfo(accessToken, (err, profile) => {
  if (profile) {
    // Get the user’s nickname and profile image
    var nickname = profile.nickname;
    var picture = profile.picture;
  }
});
Voir la mise en œuvre dansAngular 2.

​
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 devez stocker la permission initialement demandée lors du processus d’autorisation. Lorsqu’un utilisateur est autorisé, la permission scope sera également renvoyée dans l’objet authResult. Si la valeur scope dans l’objet authResult est vide, alors toutes les permissions qui ont été demandées ont été accordées. Si la valeur scope de l’objet authResult n’est pas vide, cela signifie qu’un ensemble différent de permissions a été accordé, et vous devez utiliser celles de l’objet authResult.scope. Voir la mise en œuvre dansAngular 2.

​
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 la mise en œuvre dansAngular 2.

​
Renouveler le jeton d’accès

Par mesure de sécurité, il est recommandé de limiter la durée de vie du jeton d’accès d’un utilisateur. Lorsque vous créez une API dans le , la durée de vie par défaut est de 7200 secondes (2 heures), mais elle peut être contrôlée par API. Une fois un jeton d’accès expiré, il ne peut plus être utilisé pour accéder à une API. Pour obtenir à nouveau l’accès, un nouveau jeton d’accès doit être obtenu. L’obtention d’un nouveau jeton d’accès peut être effectuée en répétant le flux d’authentification utilisé pour obtenir le jeton d’accès initial. Dans une SPA, ce n’est pas idéal, car vous ne souhaitez pas nécessairement rediriger l’utilisateur à l’écart de sa tâche actuelle pour refaire le flux d’authentification. Dans des cas comme celui-ci, vous pouvez utiliser l’authentification silencieuse. L’authentification silencieuse vous permet ainsi d’effectuer un flux d’authentification où Auth0 répondra uniquement par des redirections, et jamais par une page de connexion. Pour que cette authentification fonctionne, elle nécessite toutefois que l’utilisateur ait déjà été connecté par Authentification unique (SSO). Voir la mise en œuvre dansAngular 2.
⌘I