Bonjour,
Je programme un Web Service qui doit être vendu à des clients. Ils payent par requête au Web Service. Un cas d'utilisation typique serait que le client fasse un site Web pour ses utilisateurs finaux qui fait appel à mes Web Services.
J'aimerais bien distribuer un token d'authentification à mes clients (qui ne sont pas les utilisateurs finaux du WS). Le token est un message avec un code HMAC d'authentification. Donc le client récupère son token derrière un formulaire login/mot de passe. Il va devoir payer toutes les transactions qui ont été initiées par ce token. Donc je suppose qu'il voudra le garder secret.
Cependant j'ai vu que certain site qui utilisent des services similaires montrent un token à l'utilisateur final. Par exemple Mapbox. Et il se trouve qu'ils utilisent un système à deux tokens, un public un privé. On peut lire ça dans leur doc: https://www.mapbox.com/help/create-api-access-token/
Le client doit juste mettre ça sur ça page pour ses utilisateurs finaux. C'est très simple:
var map = L.mapbox.map('map', 'mapbox.outdoors', {
accessToken: '<your access token>'
});Et après on retrouve des tokens dans l'url (le web service a l'air de fonctionner en GET).
Apparemment il n'y a pas de problème à ce que l'utilisateur final voie le token d'identification. Quelqu'un sait comment ça marche ? C'est du OAuth ? Open ID ?
# comment ca marche ?
Posté par Xavier Combelle (site web personnel) . Évalué à 1.
Pour bien faire les token doivent être généré aléatoirement (avec un générateur d'aléa cryptographique) à mon avis. Je pense qu'utiliser un HMAC est relativement risqué pour un gain douteux.
L'utilisateur final connait un token public qui lui est spécifique, donc le client peut le révoquer, si celui ci en fait un mauvais usage.
[^] # Re: comment ca marche ?
Posté par j_m . Évalué à 1. Dernière modification le 11 octobre 2015 à 12:30.
J'aurai espéré que notre client puisse générer un token à l'intention de ses End-User, que l'on puisse, nous, les authentifier.
Et le HMAC, c'était jusqu'à présent adressé seulement à notre client. Le client se connectait à notre serveur avec son login/mot de passe. Pouvait prendre son token et s'en servir pour requêter sur nos autres serveurs. Le token contenait un id de client et le HMAC, et le serveur n'avait plus besoin que d'une clé symmétrique partagée par nos serveurs pour authentifier le client et savoir qui il est.
Mais ce qu'il serait bien c'est que le javascript du client nous envoie directement ses End-User avec un token d'authentification, qu'on puisse savoir que ça vienne de notre client.
[^] # Re: comment ca marche ?
Posté par Xavier Combelle (site web personnel) . Évalué à 1.
Le gros avantage de id+HMAC c'est le stockage en base (tu n'as que l'id a stocker)
Le fait que ce soit toi qui gère les token garanti leur unicité (le client on sait pas comment il va les générer)
Un truc important c'est la révocation des token. Si le client en génère autant qu'il veut, il faudra que potentiellement tu stocke tout ceux qui sont révoqués. Tandis que si c'est toi qui les génère, tu stocke que les token valide
[^] # Re: comment ca marche ?
Posté par j_m . Évalué à 1.
Sinon, ils sont risqués en quoi les HMAC ? J'imagine que c'est un peu plus risqué, mais aussi peut-être un peux plus léger en calcul qu'une signature avec clés asymétriques. Et dans les deux cas on peut transmettre quelques infos dans le token comme un identifiant utilisateur sans devoir faire un accès à la db.
Des token aléatoires, ça ne vas que si on passe par une db.
[^] # Re: comment ca marche ?
Posté par Xavier Combelle (site web personnel) . Évalué à 1.
un HMAC c'est risqué dans la mesure ou si le secret avec lequel il est construit fuit, n'importe qui peu en construire. De toute manière tu es obligé d'avoir une base de donnée pour stocker les secret avec lequel sont construit les hmac.
Sinon c'est aussi sur que n'importe quelle technologie cryptographique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.