Discussion :

[Leelith]

Bonjour,

Je souhaites faire un web service rest qui va être utiliser pour communiquer avec une application mobile.

Je suis relativement nouveau avec les services web de type REST, donc je me pose naturellement la question de comment authentifier l'utiliseur qui va passer par l'application.

• Première idée: lorsque l'utilisateur se connecte à l'application mobile, un cookie de session est crée, et ce cookie de session est passé à chaque requête pour assurer que l'utilisateur est bien authentifier (après vérification bien-sûr). Un peu comme à la manière d'une application web standard.
• Deuxième idée: je n'en ai pas donc je ne sais pas vraiment comment cela pourrait se faire. Des pistes?

Globalement je pense implémenter l'authentification avec les cookies, et faire la vérification a chaque requête, rien de bien différent qu'une application web.

Est-ce qu'il y a d'autres façons de faire? Je n'ai pas trouvé de tutoriel sur le forum, et les infos ne sont pas très très claire sur le net (ca vaudrait p-e le coup de faire un article là-dessus d'ailleurs ca pourrait me motiver si je fais les choses bien ). Tout exemple de code, liens, tuto etc est le bienvenu

Merci bien pour votre aide et bonne journée!

L

[Leelith]

Personne a des informations là dessus ?

[micka132]

Plutôt un Token à placer dans le header de ta requete http. Je vois plus le cookie comme un objet de stockage plus ou moins long terme qu'une session.
Bon après ça changera pas grand chose, si ce n'est que ca me parait plus simple pour un client d'avoir a gérer un header au lieu d'un cookie.

Sinon tu peux voir du coté des implémentations d'authenfication 'reconnu' comme Oauth(2).

[Leelith]

Oauth2 je connais de nom mais je ne sais absolument pas comment ça marche. Si tu as un tuto a recommander je suis preneur J'ai pas de soucis à mettre ça en place si c'est plus adapté ^^

Par contre je vois pas vraiment la différence si j'ajoute moi un header à chaque requette avec une valeur qui me servirait à savoir si oui ou non l'utilisateur est connecté (c'est un peu finalement comme un cookie comme tu le dis) avec un cookie?

edit: un des critères est que mon API va être appelée via une application mobile, je ne sais pas si cela change quelque chose?

Merci

[micka132]

Par contre je vois pas vraiment la différence si j'ajoute moi un header à chaque requette avec une valeur qui me servirait à savoir si oui ou non l'utilisateur est connecté (c'est un peu finalement comme un cookie comme tu le dis) avec un cookie?

edit: un des critères est que mon API va être appelée via une application mobile, je ne sais pas si cela change quelque chose?

La petite différence est là. Le header il y a plus de chance que ça soit géré par la majorité des API. Le cookie un peu moins dans la mesure ou le cookie est lui même un header.
Mais franchement sinon c'est exactement la même chose, ce qui va différer c'est comment tu souhaites l'utiliser:
-Soit un token qui correspond à une clef que tu as généré lors de la premier authentification, et dont tu vas a chaque appel vérifier coté serveur si tu connais bien ce token, et qu'il a bien les droits. On parle souvent de "session id" pour ce genre de processus.
-Soit un token qui va contenir tout un tas de droit/rôle que tu vas calculer la 1ere fois. Bien sur pour que ca marche il faut que ton token soit crypté . La tu peux voir de coté de JWT très populaire.

Pour OATH c'est plus large, un article interressant http://www.seedbox.com/fr/blog/2015/...uriser-un-api/

[Leelith]

Ok

Super l'article! Par contre avec OAuth, il faut monter son propre service externe d'authentification du coup ?

[Leelith]

Pas d'idée pour le service externe d'authentification alors ? :/ J'avance gentiment dans les autres aspects de mon projet cependant je vais arriver la dessus dans quelques temps et je vais me retrouver bloquer