Sécuriser une API de nœud avec les informations d'identification du client OAuth 2.0 –

Cet article a été publié à l'origine sur le blog des développeurs d'Okta . Merci de soutenir les partenaires qui rendent SitePoint possible.

La sécurisation des services d'API de serveur à serveur peut s'avérer délicate. OAuth 2.0 est un excellent moyen de décharger l'authentification utilisateur vers un autre service, mais que se passe-t-il s'il n'y a pas d'utilisateur à authentifier? Dans cet article, je vais vous montrer comment utiliser OAuth 2.0 en dehors du contexte d'un utilisateur, dans ce que l'on appelle également le flux d'informations d'identification du client.

Au lieu de stocker et de gérer les clés d'API pour vos clients (autres serveurs) , vous pouvez utiliser un service tiers pour gérer les autorisations à votre place. Cela fonctionne de la manière suivante: un client d'API envoie une demande à un serveur OAuth demandant un jeton d'API. Ce jeton est ensuite envoyé du client API à votre service API avec sa demande. Une fois que vous avez le jeton du client, vous pouvez vérifier sa validité sans avoir besoin de stocker d'informations sur le client.

Fonctionnement de la vérification du flux des informations d'identification du client

Un moyen de vérifier vos jetons recevoir à votre API le service consiste à transférer le jeton au serveur OAuth pour lui demander s'il est valide. L'inconvénient de cette méthode est que chaque requête d'API envoyée à votre serveur nécessite également une requête envoyée au serveur OAuth, ce qui augmente le temps nécessaire pour répondre à votre client. Une alternative consiste à utiliser ce qu’on appelle la validation locale, une stratégie popularisée par JSON Web Tokens (JWT). Un JWT contient vos revendications (données client) en JSON non crypté et lisible par machine.

Lorsque vous utilisez le modèle de validation local pour valider un jeton d'API (JWT), vous pouvez utiliser math pour valider ce qui suit:

Le jeton de votre API La réception n'a pas été falsifiée. Le jeton que votre API reçoit n'a pas expiré. Certaines données JSON codées dans le jeton correspondent à ce que vous attendez.

Comment est-ce sécurisé? pourrait se demander. Les JWT contiennent trois parties: un en-tête, une charge utile et une signature. L'en-tête et les données utiles sont de simples chaînes codées en base64, qui peuvent facilement être déchiffrées et lues. La signature utilise un algorithme répertorié dans l'en-tête, ainsi qu'une clé privée, pour créer un hachage de l'en-tête et de la charge utile. Le hachage ne peut pas être recréé sans la clé privée, mais il peut être vérifié avec une clé publique.

En un sens, cela ressemble à un permis de conduire ou à un passeport. Il est assez difficile de forger, mais il est très facile pour quelqu'un de regarder et de voir votre nom, votre date de naissance et d’autres informations. Vous pouvez scanner le code à barres, le tester à la lumière noire ou rechercher des filigranes pour en vérifier la validité.

Bien que le concept soit similaire, un JWT valide serait en réalité beaucoup plus difficile à forger. Une personne suffisamment compétente peut créer un permis de conduire convaincant, mais sans la clé privée, un ordinateur moderne pourrait mettre des années à forcer une signature JWT valide. Les jetons devraient également avoir une expiration. Bien qu’il soit configurable, la valeur par défaut est une heure. Cela signifie qu'un client devra demander un nouveau jeton toutes les 60 minutes s'il doit faire une nouvelle demande auprès de votre serveur API. C'est une couche de sécurité supplémentaire au cas où votre jeton serait compromis. Qui sait? Peut-être qu'un ordinateur quantique peut recréer la signature en quelques heures.

Maintenant que vous comprenez les principes de base du flux d'informations d'identification client OAuth 2.0, construisons une API de nœud qui utilise les informations d'identification du client et Okta.

Qu'est-ce qu'Okta?

En bref, nous rendons la gestion des identités plus facile, plus sûre et plus évolutive que ce à quoi vous êtes habitué. Okta est un service API qui vous permet de créer, éditer et stocker de manière sécurisée des comptes d'utilisateurs et des données de compte d'utilisateur, et de les connecter à une ou plusieurs applications. Notre API vous permet de:

Inscrivez-vous pour un compte développeur gratuit pour toujours et lorsque vous aurez terminé, revenez pour en savoir plus sur la création d'API sécurisées dans le nœud!

Créez un nœud de base API

Pour commencer, je vais vous montrer comment créer une API de base dans Node. Node conserve une liste des dépendances avec d'autres métadonnées dans un fichier nommé package.json .

En supposant que Node soit déjà installé, créez un nouveau dossier pour votre serveur API. Vous pouvez ensuite utiliser npm pour générer un package.json à votre place. La commande npm init vous demandera quelques informations, mais vous pouvez continuer à frapper . Entrez pour respecter les valeurs par défaut.

 $ mkdir client-credentials-flow
$ cd client-credentials-flow
$ git init
$ npm init

Le moyen le plus rapide de mettre en place un serveur API dans Node consiste à utiliser Express. Vous pouvez ajouter Express comme dépendance avec la commande npm install express@4.16.3 --save . Cela crée un dossier appelé node_modules où Express et tout ce dont il dépend sont téléchargés, et votre application peut ensuite les utiliser. Pour accélérer le développement, vous pouvez également ajouter une dépendance de développement appelée nodemon qui redémarrera votre serveur à chaque modification du code. Pour ajouter une dépendance de développement, utilisez l'indicateur -D : npm install -D nodemon@1.17.5