Discussion :

[Rohan21]

Bonsoir à tous,

Voila j'ai mis en place un service web REST et j'ai besoin d'authentifier mes clients.
J'ai vu qu'il existait plusieurs méthode dont celle du jeton d’authentification, que je vais détailler le fonctionnement:

L'idée consiste à envoyer, dans un 1er temps, un couple login/password et de récupérer un token en retour. Dans un second temps, ce token devra être utilisé à la place du password pour les requêtes suivantes. Ceci permet, coté serveur, de gérer la durée de validité des tokens (à 20 minutes par exemple).

Mais ce qui me pose problème, c'est que en REST il n'y a pas d'état (Stateless). Comment est ce que le serveur peut identifier le token du client?, ceci impose de faire persisté le token généré par le serveur soit en base de donné ou en session, dans les deux cas on casse le principe de REST!

Pouvez vous m'aider svp?

[David55]

Bonjour,

Ceci impose de faire persisté le token généré par le serveur soit en base de donné ou en session

Oui effectivement, une session ca peut être bien.

on casse le principe de REST!

Quel principe? C'est l'homme qui crée les principes donc on peut bien les changer
Plus sérieusement, REST est un outil, il n'y a pas vraiment de contrainte. J'utilise des sessions dans mes WS et ca n'a jamais posé de problème à personne
Ce qui veut dire que si tu as besoin de session, utilises les sessions! Surtout s'il n'y a pas d'autre solution!!!

Liens intéressants : http://blog.nicolashachet.com/niveau...e-en-5-regles/
http://stackoverflow.com/questions/6...te-restfulness

[Rohan21]

Bonjour David55,

Je pensais que le serveur ne devais pas se soucier du contexte du client. Pourquoi on dit qu'il n'y a pas d'état dans REST?

Merci pour les liens, je vais les consulter
Cdt,

[nicroman]

En tant que fervant défenseur de REST... un web-service ne peut pas être REST si il n'est pas "Stateless" (donc sans session coté serveur)...
Il ressemblera à du REST, il aura le goût du REST, mais ne sera pas vraiment REST

Le token, ton serveur y met ce qu'il veut....

Token "decrypté": {salt}:{datevalidité}:{userid}:{hash}
Le salt étant par exemple une chaine aléatoire.
datevalidité ben la durée de validité du token.
userid l'identifiant interne (souvent un nombre) de l'utilisateur.
hash un code de hash de tout ce qui précède.

Ainsi à la réception d'une requête, il "suffit" de vérifier que le "hash" est correct, que la date de validité est bonne... et bim... le userid est autorisé et validé, sans même vérifier dans la table des utilisateurs.

On peut aussi rajouter d'autres informations comme l'@ IP de l'origine.
Vérifier que le salt s'incrémente à chaque requête (ainsi un nouveau token invalidera obligatoirement le précédent), etc...

[Rohan21]

Merci David 55 pour ta réponse et pour tous ces éléments.

[David55]

Merci Rohan21 de me remercier

Mais je pense que tu voulais plutot remercier Nicroman qui a donné une réponse tout de même plus juste

[Rohan21]

Effectivement je voulais remercier nicroman , mais merci à vous deux

Je récapitule les étapes de l'authentification du client à mon service REST.

1) GET: http://api.auth/?login=monlogin?pwd=123456

2) Le serveur vérifie le couple login et pwd dans la base de donnée, le mot de passe étant crypté en md5 + clée de cryptage

3) Si OK=> Création de timestamp, Génération du token grâce à l'id du client, timestamp et clée de cryptage)

4)Le serveur répond en lui attribuant le token précédemment créer

5) Le client pour chaque nouvelle requête devra, construire la requête de cette façon GET: http://api.auth/?token=token_créer_à_letape_3

Est ce que c'est le bon déroulement?

[nicroman]

Oui... préférer le passage de token par header (X-MonApp-Auth par exemple), cela permet de bénéficier d'éventuelles mises en cache, même si le token a changé

[Rohan21]

merci beaucoup!

[Rohan21]

J'aimerai savoir si c'est risqué de d'envoyer le couple login/mdp par
GET: http://api.auth/?login=monlogin?pwd=123456

Doit on envoyer les informations au serveur par POST dans un contexte purement REST?

Merci

[David55]

En post c'est mieux et encodé encore mieux

[Rohan21]

Quel est l'inteêt d'encoder le login et le mot de passe?

[David55]

A ne pas te faire hacker? Si j'ai ton login et ton mot de passe je pourrais obtenir des infos en appelant ton WS. C'est une sécurité.

[Rohan21]

Oui mais on peut toujours décoder l'url?

[Hizin]

Si tu connais la porte, mais que tu n'as pas la clef, c'est toujours plus difficile qu'avec celle-ci.

Un peu de sécurité que diable.

[nicroman]

Déjà... surtout... utiliser https au lieu de http !!!

Après que le pwd soit dans l'url ou dans le contenu du message http, peu importe.
Et si on est en https, l'encoding n'est pas très utile.


D'autant que l'encoding fixe ne permet en rien de sécuriser l'application... surtout dans le cas du "man in the middle".
Imaginons, l'application envoie "http://xxxxxxxx/login?user=moi&pwd=monpass"... Tout va bien, ca marche, mais tout est en clair. Résultat, n'importe qui peut utiliser l'application et le login "moi / monpass"

L'application envoie "http://xxxxxxxx/login?user=moi&pwd=ZEHHABNZE" avec ZEHHABNZE l'encoding de "monpass"... Tout va bien, ça marche toujours, et personne ne peut deviner quel mot de passe va donner ZEHHABNZE.
Par contre, n'importe qui peut faire un appel à "http://xxxxxxxx/login?user=moi&pwd=ZEHHABNZE" et ainsi se faire passer pour "moi" !