Bob utilise une application Web pour réaliser quelque chose. Et:
- Son navigateur est au régime, il ne prend donc pas en charge les cookies .
- L'application Web est populaire, elle traite de nombreux utilisateurs à un moment donné - elle doit bien évoluer . Tant que le maintien de la session imposerait une limite au nombre de connexions simultanées et, bien sûr, entraînerait une pénalité de performances non négligeable , nous pourrions souhaiter avoir un système sans session :)
Quelques remarques importantes:
- nous avons la sécurité des transports ( HTTPS et ses meilleurs amis);
- derrière les rideaux, l'application Web délègue de nombreuses opérations à des services externes , au nom de l' utilisateur actuel (ces systèmes reconnaissent Bob comme l'un de leurs utilisateurs) - cela signifie que nous devons leur transmettre les informations d'identification de Bob .
Maintenant, comment authentifier Bob (sur chaque demande)? Quelle serait une manière raisonnable de mettre en œuvre une telle chose?
- jouer au tennis avec les informations d'identification via les champs masqués du formulaire HTML ... la balle contient les informations d'identification ( nom d'utilisateur et mot de passe ) et les deux raquettes sont respectivement le navigateur et l'application Web. En d'autres termes, nous pouvons transporter des données dans les deux sens via des champs de formulaire plutôt que via des cookies. À chaque demande Web, le navigateur publie les informations d'identification. Cependant, dans le cas d'une application d'une seule page , cela peut ressembler à jouer au squash contre un mur en caoutchouc, au lieu de jouer au tennis , car le formulaire Web contenant les informations d'identification peut être conservé pendant toute la durée de vie de la page Web. (et le serveur sera configuré pour ne pas offrir les informations d'identification).
- stocker le nom d'utilisateur et le mot de passe dans le contexte de la page - variables JavaScript, etc. Une seule page requise ici, à mon humble avis.
- authentification cryptée basée sur des jetons. Dans ce cas, l'action de connexion entraînerait la génération d'un jeton de sécurité chiffré (nom d'utilisateur + mot de passe + autre chose). Ce jeton sera servi au client et les demandes à venir seront accompagnées du jeton. Est-ce que ça a du sens? Nous avons déjà HTTPS ...
- autres...
- dernier recours: ne faites pas cela, stockez les informations d'identification dans la session! La session est bonne. Avec ou sans cookies.
Est-ce que des problèmes de sécurité / Web vous viennent à l'esprit, concernant l'une des idées décrites précédemment? Par exemple,
- time-out - nous pouvons conserver un horodatage , ainsi que les informations d'identification (horodatage = l'heure à laquelle Bob a entré ses informations d'identification). Par exemple, lorsque MAINTENANT - horodatage> seuil , nous pouvons refuser la demande.
- Protection contre les scripts intersites - ne devrait en aucun cas être différente, non?
Merci beaucoup d'avoir pris le temps de lire ceci :)