Configuration de l’API et de la SPA (SPAs + API)

Configuration de l’API et de la SPA pour le scénario d’architecture SPAs + API

Dans cette section, nous verrons comment mettre en place une API pour notre scénario.

Par souci de simplicité, nous limiterons notre mise en œuvre à l’authentification et à l’autorisation. Comme vous le verrez dans les exemples, l’entrée de feuille de temps sera codée en dur et l’API n’enregistrera pas cette entrée. Elle renverra simplement une partie des 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’API est une URL unique qui représente un objet. Pour interagir avec cet objet, votre application doit être dirigée vers son URL. Par exemple, si vous aviez une API capable de renvoyer soit des commandes, soit des clients, vous pourriez configurer deux points de terminaison : /orders et /customers. Votre application interagirait avec ces points de terminaison au moyen de différentes méthodes HTTP ; par exemple, POST /orders pourrait créer une nouvelle commande ou GET /orders pourrait récupérer le jeu de données d’une ou de plusieurs commandes.

Pour cette mise en œuvre, nous ne définirons que 2 points de terminaison ; un pour récupérer la liste de toutes les feuilles de temps d’un employé, et un autre qui permettra à 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 entrée de feuille de temps.

Voir la mise en œuvre en Node.js.

​

Sécuriser les points de terminaison

Lorsqu’une API reçoit une requête avec un jeton d’accès bearer dans l’en-tête, la première chose à faire est de valider le jeton. Cela comprend une série d’étapes, et si l’une d’elles échoue, la requête doit être rejetée avec le message d’erreur Missing or invalid token à l’intention de l’application appelante.

Les validations que l’API doit effectuer sont les suivantes :

• Vérifier que le JWT est bien formé
• Vérifier la signature
• Valider les claims standard

JWT.io fournit une liste de bibliothèques qui peuvent faire l’essentiel du travail pour vous : analyser le JWT, vérifier la signature et les claims.

Le processus de validation comprend aussi la vérification des Application permissions (scopes), mais nous y reviendrons séparément dans le paragraphe suivant de ce document.

Pour en savoir plus sur la validation des jetons d’accès, consultez Validate Access Tokens.

Voir la mise en œuvre dans Node.js.

​

Vérifier les permissions de l’application

À ce stade, nous avons vérifié que le 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 scopes du JWT décodé. Ce claim fait partie du payload, et il s’agit d’une liste de chaînes séparées par des espaces.

Consultez la mise en œuvre dans Node.js.

​

Déterminer l’identité de l’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é de l’utilisateur.

Pour récupérer la liste des feuilles de temps, il faut s’assurer que nous retournons uniquement les feuilles de temps qui appartiennent à l’utilisateur qui effectue la requête; pour ajouter une nouvelle feuille de temps, il faut s’assurer que celle-ci est associée à l’utilisateur qui effectue la requête.

L’une des claims JWT standard est la claim sub, qui identifie le principal auquel la claim se rapporte. Dans le cas du flow Implicit Grant, cette claim contiendra l’identité de l’utilisateur, c’est-à-dire l’identifiant unique de l’utilisateur Auth0. Vous pouvez vous en servir pour associer des informations dans des systèmes externes à un utilisateur précis.

Vous pouvez aussi utiliser une custom claim pour ajouter un autre attribut de l’utilisateur — comme son adresse courriel — à l’access token et vous en servir pour identifier l’utilisateur de façon unique.

Consultez la mise en œuvre dans Node.js.

​

Mettre en place la SPA

Dans cette section, nous verrons comment mettre en place une SPA dans notre scénario.

​

Autoriser l’utilisateur

Pour autoriser l’utilisateur, nous allons utiliser la bibliothèque auth0.js. Vous pouvez initialiser une nouvelle instance de l’application Auth0 comme suit :

Vous devez transmettre les valeurs de configuration suivantes :

• clientID : La valeur de votre Client Id Auth0. Vous pouvez la récupérer dans les Settings de votre Application du Dashboard.
• domain : La valeur de votre domaine Auth0. Vous pouvez la récupérer dans les Settings de votre Application du Dashboard.
• responseType : Indique le flux d’authentification à utiliser. Pour une SPA qui utilise l’Implicit Flow, cette valeur doit être définie sur token id_token. La partie token déclenche le renvoi d’un jeton d’accès dans le fragment d’URL, tandis que la partie id_token déclenche également le renvoi d’un ID Token.
• audience : La valeur de votre identifiant d’API. Vous pouvez la récupérer dans les Settings de votre API du Dashboard.
• redirectUri : L’URL vers laquelle Auth0 doit rediriger l’utilisateur après son authentification.
• scope : Les scopes qui déterminent les renseignements à renvoyer dans le ID Token et le jeton d’accès. Un scope de openid profile renverra tous les renseignements du profil utilisateur dans le ID Token. Vous devez aussi demander les scopes requis pour appeler l’API, dans ce cas-ci les scopes read:timesheets create:timesheets. Cela garantira que le jeton d’accès possède ces scopes.

Pour lancer le flux d’authentification, vous pouvez appeler la méthode authorize() :

auth0.authorize();

Après l’authentification, Auth0 vous redirigera vers le redirectUri que vous avez indiqué lors de la configuration de la nouvelle instance de l’application Auth0. À cette étape, vous devrez appeler la méthode parseHash() , qui analyse un fragment de hachage d’URL afin d’extraire le résultat d’une réponse d’authentification Auth0.

Le contenu de l’objet authResult renvoyé par parseHash dépend des paramètres d’authentification utilisés. Il peut inclure les éléments suivants :

• idToken : un JWT ID Token contenant des renseignements du profil utilisateur
• accessToken : un jeton d’accès pour l’API, spécifié par l’audience.
• expiresIn : une chaîne contenant la durée d’expiration (en secondes) du jeton d’accès.

Déterminez où il convient le mieux de stocker les jetons. Si votre application monopage a un serveur backend, les jetons doivent être gérés côté serveur au moyen du Authorization Code Flow ou du Authorization Code Flow with Proof Key for Code Exchange (PKCE).

Si vous avez une application monopage (SPA) sans serveur backend correspondant, votre SPA devrait demander de nouveaux jetons à la connexion et les conserver en mémoire sans les enregistrer. Pour effectuer des appels d’API, votre SPA utiliserait alors la copie en mémoire du jeton.

Pour un exemple de gestion des sessions dans les SPA, consultez la section Gérer les jetons d’authentification du Quickstart pour application monopage en Javascript.

Voir la mise en œuvre avec Angular 2.

​

Obtenir le profil de l’utilisateur

Extraire des informations du jeton

Cette section montre comment récupérer les informations de l’utilisateur à l’aide du jeton d’accès et du point de terminaison /userinfo. Pour éviter cet appel d’API, vous pouvez simplement décoder le ID Token à l’aide d’une bibliothèque (assurez-vous de d’abord le valider). Si vous avez besoin de renseignements supplémentaires sur l’utilisateur, envisagez d’utiliser notre Management API à partir de votre backend.

La méthode client.userInfo peut être appelée en lui passant le authResult.accessToken retourné afin de récupérer les informations du profil de l’utilisateur. Elle enverra 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": "[e-mail]",
    "clientID": "AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH",
    "updated_at": "2017-02-07T20:50:33.563Z",
    "name": "[e-mail]",
    "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 à n’importe laquelle de ces propriétés dans la fonction de rappel fournie lors de l’appel de la fonction userInfo :

const accessToken = authResult.accessToken;

auth0.client.userInfo(accessToken, (err, profile) => {
  if (profile) {
    // Récupérer le surnom et l'image de profil de l'utilisateur
    var nickname = profile.nickname;
    var picture = profile.picture;
  }
});

Consultez la mise en œuvre dans Angular 2.

​

Afficher conditionnellement des éléments de l’interface utilisateur en fonction du scope

En fonction du scope de l’utilisateur, vous pourriez souhaiter afficher ou masquer certains éléments de l’interface utilisateur. Pour déterminer le scope accordé à un utilisateur, vous devrez stocker le scope initialement demandé lors du processus d’autorisation. Une fois l’utilisateur autorisé, le scope sera également renvoyé dans authResult.

Si le scope dans authResult est vide, cela signifie que tous les scopes demandés ont été accordés. Si le scope dans authResult n’est pas vide, cela signifie qu’un ensemble différent de scopes a été accordé, et vous devriez utiliser ceux de authResult.scope.

Voir la mise en œuvre dans Angular 2.

​

Faire une requête à l’API

Pour accéder aux ressources sécurisées de votre API, le jeton d’accès de l’utilisateur authentifié doit être inclus dans les requêtes qui lui sont adressées. Pour ce faire, envoyez le jeton d’accès dans un en-tête Authorization à l’aide du schéma Bearer.

Consultez la mise en œuvre dans Angular 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 Auth0 Dashboard, la durée de vie par défaut est de 7200 secondes (2 heures), mais vous pouvez la définir pour chaque API.

Une fois expiré, un jeton d’accès ne peut plus être utilisé pour accéder à une API. Pour y accéder de nouveau, vous devez obtenir un nouveau jeton d’accès.

Pour obtenir un nouveau jeton d’accès, vous pouvez répéter le flux d’authentification utilisé pour obtenir le jeton d’accès initial. Dans une SPA, ce n’est pas l’idéal, car vous ne voudrez peut-être pas rediriger l’utilisateur hors de sa tâche en cours pour qu’il recommence le flux d’authentification.

Dans ce type de situation, vous pouvez utiliser l’authentification silencieuse. L’authentification silencieuse vous permet d’exécuter un flux d’authentification dans lequel Auth0 répond uniquement par des redirections, jamais avec une page de connexion. Cela exige toutefois que l’utilisateur ait déjà ouvert une session au moyen de l’authentification unique (SSO).

Voir la mise en œuvre dans Angular 2.