Authentification par jeton ou cookies

Question

Quelle est la différence entre l'authentification par jeton et l'authentification par cookies ?

J'essaie de mettre en œuvre la Ember Auth Rails Demo mais je ne comprends pas les raisons de l'utilisation de l'authentification par jeton telle que décrite dans le document FAQ Ember Auth sur la question "Pourquoi l'authentification par jeton ?"

Answer 1

Http est apatride. Pour être autorisé, vous devez "signer" chaque requête que vous envoyez au serveur.

Authentification par jeton

• Une requête adressée au serveur est signée par un "jeton" - généralement, il s'agit de définir des en-têtes http spécifiques, mais ils peuvent être envoyés dans n'importe quelle partie de la requête http (corps du POST, etc.).

• Pour :

  • Vous ne pouvez autoriser que les demandes que vous souhaitez autoriser. (Les cookies - même le cookie d'autorisation - sont envoyés pour chaque demande).
  • Immunisé contre le XSRF (Bref exemple de XSRF - je vous enverrai un lien par courriel qui ressemblera à ceci <img src="http://bank.com?withdraw=1000&to=myself" /> et si vous êtes connecté via une authentification par cookie à bank.com, et que bank.com n'a aucun moyen de protection XSRF, je retirerai de l'argent de votre compte simplement par le fait que votre navigateur déclenchera une requête GET autorisée vers cette url). Notez qu'il existe des mesures anti-falsification que vous pouvez prendre avec l'authentification basée sur les cookies - mais vous devez les mettre en œuvre.
  • Les cookies sont liés à un seul domaine. Un cookie créé sur le domaine foo.com ne peut pas être lu par le domaine bar.com, alors que vous pouvez envoyer des jetons à n'importe quel domaine. C'est particulièrement utile pour les applications à page unique qui consomment plusieurs services nécessitant une autorisation. Ainsi, je peux avoir une application Web sur le domaine myapp.com qui peut faire des demandes autorisées côté client à myservice1.com et à myservice2.com.

• Cons :

  • Vous devez stocker le jeton quelque part, alors que les cookies sont stockés "hors de la boîte". Les emplacements qui me viennent à l'esprit sont localStorage (contre : le jeton est conservé même après la fermeture de la fenêtre du navigateur), sessionStorage (pour : le jeton est jeté après la fermeture de la fenêtre du navigateur, contre : l'ouverture d'un lien dans un nouvel onglet rendra cet onglet anonyme) et cookies (pour : le jeton est jeté après la fermeture de la fenêtre du navigateur. Si vous utilisez un cookie de session, vous serez authentifié lorsque vous ouvrirez un lien dans un nouvel onglet, et vous serez à l'abri de XSRF puisque vous ne tenez pas compte du cookie pour l'authentification, vous l'utilisez simplement comme stockage de jeton. Contre : les cookies sont envoyés pour chaque requête. Si ce cookie n'est pas marqué comme étant uniquement https, vous êtes ouvert aux attaques de type man in the middle).
  • Il est légèrement plus facile de faire une attaque XSS contre l'authentification basée sur le jeton (c'est-à-dire que si je suis capable d'exécuter un script injecté sur votre site, je peux voler votre jeton ; cependant, l'authentification basée sur le cookie n'est pas non plus une solution miracle - alors que les cookies marqués comme http-only ne peuvent pas être lus par le client, le client peut toujours faire des demandes en votre nom qui incluront automatiquement le cookie d'autorisation).
  • Les demandes de téléchargement d'un fichier, qui ne sont censées fonctionner que pour les utilisateurs autorisés, nécessitent l'utilisation de l'API Fichier. La même demande fonctionne d'emblée pour l'authentification basée sur les cookies.

Authentification des cookies

• Une demande au serveur est toujours signée par un cookie d'autorisation.
• Pour :
  • Les cookies peuvent être marqués comme "http-only", ce qui les rend impossibles à lire du côté client. Cette option est préférable pour la protection contre les attaques XSS.
  • Il est prêt à l'emploi - vous n'avez pas besoin d'implémenter de code du côté client.
• Cons :
  • Lié à un seul domaine. (Donc, si vous avez une application à page unique qui fait des demandes à plusieurs services, vous pouvez finir par faire des choses folles comme un proxy inverse).
  • Vulnérable au XSRF. Vous devez prendre des mesures supplémentaires pour protéger votre site contre la falsification des requêtes intersites.
  • sont envoyés pour chaque demande, (même pour les demandes qui ne nécessitent pas d'authentification).

Globalement, je dirais que les jetons vous donnent une meilleure flexibilité (puisque vous n'êtes pas lié à un seul domaine). L'inconvénient est que vous devez faire un peu de codage par vous-même.

Answer 2

Pour les Googlers :

• NE PAS mélanger Garantie d'état avec mécanismes de transfert d'état

STATEFULNESS

• Stateful \= enregistrer les informations d'autorisation du côté du serveur, c'est la méthode traditionnelle.
• Apatride \= enregistrer les informations d'autorisation côté client, ainsi qu'une signature pour garantir l'intégrité.

MÉCANISMES

• Cookie \= un en-tête spécial avec un traitement particulier (accès, stockage, expiration, sécurité, transfert automatique) par les navigateurs
• Collecteurs personnalisés \= par exemple Authorization sont juste des en-têtes sans traitement spécial, le client doit gérer tous les aspects du transfert.
• Autre . D'autres mécanismes de transfert peuvent être utilisés, par exemple, la chaîne de requête a été un choix pour transférer l'ID d'authentification pendant un certain temps, mais a été abandonnée en raison de son manque de sécurité.

COMPARAISON DE L'ÉTAT D'AVANCEMENT

• "Autorisation avec état" signifie que le serveur stocke et conserve les informations relatives à l'autorisation de l'utilisateur sur le serveur, ce qui fait que les autorisations font partie de l'état de l'application.
• Cela signifie que le client ne doit conserver qu'un "auth ID" et que le serveur peut lire les détails de l'authentification dans sa base de données.
• Cela implique que le serveur conserve un pool d'authentifiants actifs (utilisateurs connectés) et qu'il interroge cette information pour chaque requête.
• L'expression "autorisation sans état" signifie que le serveur ne stocke pas et ne conserve pas les informations d'authentification de l'utilisateur, il ne sait simplement pas quels utilisateurs sont connectés et compte sur le client pour produire ces informations.
• Le client stockera des informations d'authentification complètes, comme l'identité de l'utilisateur (ID utilisateur), et éventuellement les autorisations, la date d'expiration, etc. jeton
• Il est évident qu'on ne peut pas faire confiance au client, donc les données d'authentification sont stockées avec une signature générée à partir de l'application hash(data + secret key) où la clé secrète n'est connue que du serveur, de sorte que l'intégrité des données du jeton peut être vérifiée.
• Notez que le mécanisme de jeton garantit simplement l'intégrité, mais pas la confidentialité, le client doit mettre en œuvre ce mécanisme.
• Cela signifie également que pour chaque demande, le client doit soumettre un jeton complet, ce qui entraîne une augmentation de la bande passante.

COMPARAISON DES MÉCANISMES

• Le "cookie" n'est qu'un en-tête, mais avec des opérations préchargées sur les navigateurs.
• Le cookie peut être défini par le serveur et sauvegardé automatiquement par le client, et sera envoyé automatiquement pour le même domaine.
• Le cookie peut être marqué comme httpOnly empêchant ainsi l'accès JavaScript du client
• Les opérations préchargées peuvent ne pas être disponibles sur des plates-formes autres que les navigateurs (par exemple, les mobiles), ce qui peut entraîner des efforts supplémentaires
• Les "en-têtes personnalisés" sont simplement des en-têtes personnalisés sans opérations préchargées.
• Le client est responsable de la réception, du stockage, de la sécurisation, de la soumission et de la mise à jour de la section d'en-tête personnalisée pour chaque demande, ce qui peut contribuer à empêcher l'intégration de certains URL malveillants simples

SOMMAIRE

• Il n'y a pas de magie, l'état de l'authentification doit être stocké quelque part, soit sur le serveur, soit sur le client.
• Vous pouvez implémenter le mode avec ou sans état avec un cookie ou d'autres en-têtes personnalisés.
• Lorsque les gens parlent de ces choses, leur état d'esprit par défaut est le suivant : apatride = jeton + en-tête personnalisé, avec état = ID d'authentification + cookie ; ce ne sont PAS les seules options possibles.
• Ils ont des avantages et des inconvénients, mais même pour les jetons cryptés, vous ne devez pas stocker d'informations sensibles.

Answer 3

Une application web typique est principalement apatride en raison de son demande/réponse nature. Le protocole HTTP est le meilleur exemple d'un protocole de type apatride protocole. Mais comme la plupart des applications web ont besoin état afin de tenir le état entre le serveur et le client, les cookies sont utilisés de telle sorte que le serveur peut envoyer un cookie dans chaque réponse au client. Cela signifie que la prochaine demande faite par le client comprendra ce cookie et sera donc reconnue par le serveur. De cette façon, le serveur peut maintenir un session avec le apatride client, connaissant presque tout du fonctionnement de l'application. état mais stocké sur le serveur. Dans ce scénario, à aucun moment le client ne détient état ce qui n'est pas le cas Ember.js travaux.

Dans Ember.js, les choses sont différentes. Ember.js facilite le travail du programmeur parce qu'il détient en effet la état pour vous, dans le client, en connaissant à chaque instant son état sans avoir à faire une requête au serveur pour demander état données.

Cependant, en tenant état dans le client peut aussi parfois introduire des problèmes de concurrence qui ne sont tout simplement pas présents dans apatride situations. Ember.js, cependant, traite également ces questions pour vous ; ember-data est spécifiquement construit dans cet esprit. En conclusion, Ember.js est un framework conçu pour avec état clients.

Ember.js ne fonctionne pas comme une entreprise typique apatride l'application web où le session le état et les cookies correspondants sont presque entièrement gérés par le serveur. Ember.js tient son état entièrement en Javascript (dans la mémoire du client, et non dans le DOM comme certains autres frameworks) et n'a pas besoin du serveur pour gérer la session. Ember.js est donc plus polyvalent dans de nombreuses situations, par exemple lorsque votre application est en mode hors ligne.

Évidemment, pour des raisons de sécurité, il faut une sorte de jeton o clé unique doit être envoyée au serveur à chaque fois qu'une demande est faite afin d'être authentifié . De cette façon, le serveur peut consulter le jeton d'envoi (qui a été initialement émis par le serveur) et vérifier s'il est valide avant de renvoyer une réponse au client.

À mon avis, la principale raison pour laquelle il faut utiliser un jeton d'authentification plutôt que des cookies comme indiqué dans le document FAQ Ember Auth est principalement due à la nature du cadre Ember.js et aussi parce qu'elle s'inscrit davantage dans le cadre de l'approche de l avec état paradigme de l'application web. Le mécanisme des cookies n'est donc pas la meilleure approche pour construire une application Ember.js.

J'espère que ma réponse donnera plus de sens à votre question.

Answer 4

• Les jetons doivent être stockés quelque part (stockage local/session ou cookies).

• Les jetons peuvent expirer comme les cookies, mais vous avez plus de contrôle.

• Le stockage local/session ne fonctionne pas sur plusieurs domaines, utilisez un cookie de marquage.

• Les demandes de contrôle préalable seront envoyées à chaque demande CORS.

• Lorsque vous avez besoin de streamer quelque chose, utilisez le jeton pour obtenir une requête signée.

• Il est plus facile de traiter le XSS que le XSRF.

• Le jeton est envoyé à chaque demande, faites attention à sa taille.

• Si vous stockez des informations confidentielles, cryptez le jeton.

• Les jetons Web JSON peuvent être utilisés dans OAuth

• Les jetons ne sont pas des solutions miracles. Réfléchissez bien à vos cas d'utilisation des autorisations.

http://blog.auth0.com/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/

Answer 5

Je crois qu'il y a une certaine confusion ici. La différence significative entre l'authentification basée sur les cookies et ce qui est maintenant possible avec Stockage Web HTML5 est que les navigateurs sont conçus pour envoyer des données de cookies lorsqu'ils demandent des ressources au domaine qui les a définies. Vous ne pouvez pas empêcher cela sans désactiver les cookies. Navigateurs n'envoyez pas de données depuis le stockage Web, sauf si le code de la page les envoie. . Et les pages ne peuvent accéder qu'aux données qu'elles ont stockées, et non aux données stockées par d'autres pages.

Ainsi, un utilisateur inquiet de la manière dont ses données de cookies peuvent être utilisées par Google ou Facebook peut désactiver les cookies. Mais il a moins de raisons de désactiver le stockage Web (jusqu'à ce que les annonceurs trouvent un moyen de l'utiliser également).

C'est donc la différence entre les cookies et les jetons, ces derniers utilisant le stockage Web.