2017-10-04 1 views
0

Depuis quelques mois, je travaille sur une API Rest pour une application Web pour l'entreprise pour laquelle je travaille. Les points d'extrémité fournissent des données telles que l'historique des transactions, les données utilisateur et les données pour les tickets de support. Cependant, je continue à courir sur un problème qui semble toujours me remettre dans une certaine mesure.Comment gérer en toute sécurité l'authentification utilisateur de l'API Rest?

Le problème que je ne cesse de rencontrer est de savoir comment gérer de manière sécurisée l'authentification de l'utilisateur pour l'API Rest. Toutes les données vont être envoyées via une connexion SSL, mais il y a une partie de moi qui est paranoïaque sur les problèmes de sécurité potentiels qui pourraient survenir. À l'heure actuelle, lorsqu'un client tente de se connecter, le client doit fournir un nom d'utilisateur ou une adresse e-mail et un mot de passe à un point de connexion (E.G "/ api/login"). Parallèlement à ces informations, une empreinte digitale du navigateur doit être fournie via l'en-tête de la demande qui envoie les informations de connexion. L'API valide ensuite si l'utilisateur spécifié existe ou non, vérifie si le mot de passe fourni est correct et stocke l'empreinte dans un modèle de base de données. Pour accéder à tous les autres points de terminaison de l'API, un jeton valide de connexion et une empreinte de navigateur valide sont requis. J'ai utilisé les empreintes digitales du navigateur pour empêcher le piratage de jetons, et pour m'assurer que le même périphérique utilisé pour se connecter est utilisé pour effectuer les demandes. Cependant, j'ai remarqué un scénario où cette pratique se retourne contre moi. La bibliothèque côté client que j'utilise pour générer des empreintes de navigateur n'est pas toujours précise. Parfois, la bibliothèque crache une empreinte digitale différente entièrement. Ce qui provoque l'échec de certaines demandes client car l'empreinte digitale différente n'est pas reconnue par l'API comme étant valide. Je souhaite savoir quels périphériques sont utilisés pour envoyer des demandes à l'API. Y a-t-il une façon plus cohérente de le faire, tout en protégeant les jetons contre le piratage?

En pensant à la question précédente, il y en a une autre qui vient aussi à l'esprit. Comment stocker en toute sécurité des jetons authentiques sur le client, ou d'une manière qui rend difficile l'obtention de jetons par des moyens malveillants tels qu'une attaque xss? Je comprends que la définition d'une politique stricte de sécurité du contenu sur les clients basés sur un navigateur peut être efficace pour se défendre contre les attaques xss. Cependant, je suis toujours paranoïaque sur le stockage des jetons comme des cookies ou dans le stockage local. Je sais que oauth2 est généralement une bonne solution pour l'authentification de l'utilisateur, et j'ai envisagé de l'utiliser avant pour résoudre ce problème. Bien que j'écris l'API en utilisant Flask, j'utilise aussi des jetons Web JSON. À l'heure actuelle, l'implémentation de oauth2 par Flask n'a aucun moyen d'utiliser les JWT en tant que jetons d'accès lors de l'utilisation d'oauth pour l'authentification.

Ceci est mon premier projet à grande échelle où j'ai dû faire face à ce problème et je ne sais pas quoi faire. Toute aide, conseil ou critique sont appréciés. J'ai besoin de l'aide maintenant.

Répondre

0

Mettez une passerelle API devant votre API, votre API Gateway est publiquement exposée (c'est-à-dire dans la zone démilitarisée) alors que les API réelles sont internes. Vous pouvez regarder dans Kong ..