Espace privé et webservices

Bonjour,


 


Je débute doucement une (première) application, qui est basée sur des appels à  des webservices d'un site (écrit en PHP). Dans cette application, il devra y avoir un espace privé auquel seuls les membres inscrits sur le site pourront avoir accès.


 


Donc, je pars du principe général qu'on arrive en tout premier lieu sur une page de connexion classique avec identifiant/mot de passe, qui sont envoyés à  un webservice qui vérifie donc le couple. Selon la réponse du service, on arrive donc soit sur la page privée, soit sur une page d'erreur. Jusqu'ici tout va bien.


 


Maintenant, cette espace privé donne accès à  plusieurs fonctions, qui ne devront être accessibles qu'après connexion. Et là  commencent mes problèmes. à‰videmment, il ne faut pas que l'authentification ne soit demandée à  chaque appel à  un webservice, mais uniquement si la "session" est expirée...


 


Comment gérez-vous ça ? Venant du monde web, je pense immédiatement aux sessions : le service PHP créerait une variable de session qui serait réutilisée par les appels ultérieurs... Mais je suspecte que ce n'est pas comme ça que ça doit se faire : si l'utilisation est interrompue, la session peut expirer...


 


Stockage een local sur l'app d'un identifiant spécifique qui est renvoyé par le premier service d'authentification et retransmis à  chaque appels de webservice ?


 


Je ne me vois tout de même pas faire transiter à  chaque appel l'identifiant et le mot de passe...


 


J'espère que je suis assez clair. Merci pour votre aide !


 


 


Réponses

  • AliGatorAliGator Membre, Modérateur
    avril 2014 modifié #2
    Fait passer le token (ou le PHPSessionID) dans les cookies. ça sera automatiquement géré par le NSHTTPCookieStorage et tu n'auras rien à  gérer.


    Sinon, la méthode classique c'est de faire passer le token d'authentification (ce que tu appelles identifiant spécifique) dans les headers de tes requêtes (Authentication: Bearer xxx etc)


    Dans tous les cas, session PHP ou token ou autre, il faut absolument une expiration. Sinon un attaque type "Man In The Middle" est encore plus facilitée car tu ne te protège même pas des "Replays". Donc il faut que le token (qui est surtout là  à  la fois pour éviter de trop faire transiter le login/mdp à  chaque fois en clair mais aussi pour éviter que côté serveur il réinterroge la base des utilisateurs à  chaque appel) expire.


    Après si tu ne veux pas que l'utilisateur saisisse son login/mdp à  nouveau quand le token aura expiré tu peux toujours stocker login/pwd dans la Keychain iOS, après tout c'est justement fait pour et ça permet de les stocker semainière sécurisée.


    Enfin, faire tous tes requêtes sur du HTTPS permettra que tes échanges soient sécurisés et chiffrés.
  • Ok, merci beaucoup de la réponse. Donc c'est bien la solution du token d'identification qui me paraà®t la meilleure (quand je parlais d'expiration, je pensais surtout à  l'expiration de la session pendant le processus, entre deux appels).


    Il y a quand même un point qui reste flou pour moi, en ce qui concerne la sécurité. Si un simple token sert d'authentification pour le webservice, comment construire ce fameux token ? Le numéro identifiant de l'utilisateur est insuffisant , non ?


    En tous cas, merci pour ta réponse, elle m'a déjà  permis de clarifier un peu les choses dans mon esprit.
  • AliGatorAliGator Membre, Modérateur
    Bah c'est un token, ou "nonce" ou quoi donc en gros un identifiant généré aléatoirement quoi. Et que tu gardes dans ta $_SESSION côté PHP pour le comparer avec celui que ton client iPhone va te renvoyer à  chaque requête.


    Bref de l'authentification tout ce qu'il y a de plus classique, qui n'est en rien spécifique avec Objective-C, Cocoa ou le monde mobile
  • Oui, c'est vrai que ça n'a plus rien à  voir, en effet. Bon, je crois avoir compris comment faire. Merci :)


Connectez-vous ou Inscrivez-vous pour répondre.