Gestion des tokens fontend/backend

Bonjour,

je développe une application web où j’ai un backend écrit en Node.js hébergé sur AWS et un frontend en Angular. En ce moment je dois gérer la connection à mon service et à d’autres services tiers et j’ai des difficultés à comprendre la bonne façon d’utiliser les tokens.

Par exemple pour appeler les routes de mon backend, il me faut un token de connexion pour y avoir accès. Est-ce un problème de l’envoyer par paramètre GET ou POST depuis le front au back ? Y a t-il des risques de sécurité ? Lorsque quelqu’un possède ce token il peut facilement utiliser un client REST pour appeler nimporte quelle route de l’application.

Dans mon service l’utilisateur doit également se connecter à Facebook et utiliser le token pour effectuer un certain nombre d’opérations. Ce token peut être directement utilisé sur l’explorateur d’API Facebook pour appeler les routes de l’API Facebook. Est-ce un problème de l’envoyer du front au back ? Ou tout doit-il être géré depuis le back ?

J’aurais besoin d’un peu de clarté là-dessus. Merci de votre aide

Les API prévoient le cas avec un Client ID public cependant il demande la connexion de l’utilisateur à ton application (attention! Il faut garder ton token private). Dans ton cas c’est l’Implicit Grant

Le schéma :

Ton bouton vers la page de connexion du service http://fb.com/ —> La page de connexion du service http://fb.com/ —> Le service renvoie l’utilisateur sur la page de retour indiqué sur ton site http://tonsite.com/auth.html#lasecretkeydansunhashtag.

Salut !

Les tokens de connexion sont plus souvent envoyés au backend dans les headers (souvent "Authorization" ou "X-Authorization") de la requêtes : cela permet de gérer leur transmission de la même manière que ce soit pour une requête POST qu’une requête GET (qui ne peut pas contenir de corps elle).

Pour limiter les risques de fuite du token, ces derniers sont souvent limités avec une date d’expiration. Plus elle sera courte, plus les risques seront limités mais il faudra renouveler ce token plus souvent. Il est également possible de mettre en place une blacklist de token (dans une table de BDD souvent), permettant à tout moment de rendre un token caduque. Dans ce cas, il peut être intéressant d’utiliser deux tokens au lieu d’un : un token d’accès passé à ton backend à chaque appel qui a une très courte durée de vie mais qui ne peut pas être blacklisté (cela limite la charge de ta base de données en permettant à ton backend de ne pas avoir à la requêter à chaque appel pour regarder s’il est blacklisté) et un token de renouvellement qui sert justement à obtenir de nouveaux tokens d’accès (lors du renouvellement, il est bien recherché dans la blacklist pour savoir s’il est toujours valide). Ainsi, le token d’accès est tout le temps passé à ton backend pour authentifier l’utilisateur et le token de renouvellement est seulement donné au service de renouvellement de token quand nécessaire.

Pour ce qui est de la connexion à Facebook, à ta place, j’essaierai de tout gérer à un seul endroit : le backend (car j’imagine que dans tous les cas, il aura besoin d’accès à l’API de Facebook).

Du coup si je comprends bien c’est parfaitement OK d’envoyer un token du frontend au backend ?

Concernant facebook :

• J’ai besoin d’enregistrer certaines données en base lors de la récupération du token. C’est pour ça que j’ai besoin d’effectuer la redirection sur le front;
• Lors de cette redirection on récupère deux token, access_token (longue durée) et refresh token (courte durée), du coup si je comprends bien c’est mieux d’utiliser le refresh_token ?
• J’avais prévu au départ de tout faire depuis le back et d’enregistrer le token dans la base de donnée. Est-ce une bonne pratique ?

Si tu as besoin de donnée pour ta base de donnée, tu dois faire tout côté back-end (sauf bien entendu la demande d’auth).