En termes très simples, quelqu'un peut-il expliquer la différence entre OAuth 2 et OAuth 1 ?
OAuth 1 est-il désormais obsolète ? Devrions-nous mettre en œuvre OAuth 2 ? Je ne vois pas beaucoup de mises en œuvre d'OAuth 2 ; la plupart utilisent encore OAuth 1, ce qui me fait douter qu'OAuth 2 soit prêt à être utilisé. Est-ce le cas ?
Eran Hammer-Lahav a fait un excellent travail en expliquant la majorité des différences dans son article. Présentation d'OAuth 2.0 . Pour résumer, voici les principales différences :
Plus de flux OAuth pour permettre une meilleure prise en charge des applications non basées sur un navigateur. C'est l'une des principales critiques formulées à l'encontre d'OAuth par les applications clientes qui n'étaient pas basées sur un navigateur. Par exemple, dans OAuth 1.0, les applications de bureau ou de téléphonie mobile devaient demander à l'utilisateur d'ouvrir son navigateur vers le service souhaité, de s'authentifier auprès du service et de copier le jeton du service vers l'application. La principale critique ici concerne l'expérience utilisateur. Avec OAuth 2.0, il existe désormais de nouveaux moyens pour une application d'obtenir l'autorisation d'un utilisateur.
OAuth 2.0 n'exige plus que les applications clientes disposent d'une cryptographie. Cela rappelle l'ancienne API Twitter Auth, qui ne nécessitait pas que l'application hachât les jetons et les chaînes de requête par HMAC. Avec OAuth 2.0, l'application peut faire une demande en utilisant uniquement le jeton émis sur HTTPS.
Les signatures OAuth 2.0 sont beaucoup moins compliquées. Plus d'analyse syntaxique, de tri ou d'encodage spéciaux.
Les jetons d'accès OAuth 2.0 sont "de courte durée". En général, les jetons d'accès OAuth 1.0 peuvent être stockés pendant un an ou plus (Twitter ne les laisse jamais expirer). OAuth 2.0 a la notion de jetons de rafraîchissement. Bien que je ne sois pas tout à fait sûr de ce qu'ils sont, je suppose que vos jetons d'accès peuvent être de courte durée (c'est-à-dire basés sur une session) tandis que vos jetons de rafraîchissement peuvent être "à vie". Vous utiliseriez un jeton de rafraîchissement pour acquérir un nouveau jeton d'accès plutôt que de demander à l'utilisateur de réautoriser votre application.
Enfin, OAuth 2.0 est censé assurer une séparation nette des rôles entre le serveur chargé de traiter les demandes OAuth et le serveur chargé de l'autorisation des utilisateurs. De plus amples informations à ce sujet sont détaillées dans l'article susmentionné.
OAuth 2.0 ne supplantera OAuth que si elle est approuvée en tant que RFC. Il s'agit actuellement d'un projet Internet, mais il est prévu qu'il devienne une norme Internet (pour autant que ces choses puissent être planifiées). Toutefois, cela prendra des années, car une grande partie du cadre n'est pas encore spécifiée. Nous verrons probablement toute une famille d'Internet Drafts être publiés dans les années à venir, chacun concernant différents aspects du cadre d'autorisation OAuth 2.0. Pour comprendre pourquoi, visitez tools.ietf.org/html/draft-ietf-oauth-v2 et recherchez "beyond the scope of this specification" ;)
L'auteur de l'article a rédigé l'année dernière un suivi intitulé "OAuth 2.0 and the Road to Hell", qui peut être lu ici : web.archive.org/web/20120731155632/http://hueniverse.com/2012/ Une différence importante entre les deux est la sécurité - comme le laisse présager l'absence de cryptographie dans la version 2.0.
Les explications précédentes sont toutes trop détaillées et compliquées, selon moi. Pour faire simple, OAuth 2 délègue la sécurité au protocole HTTPS. OAuth 1 ne l'exigeait pas et disposait par conséquent de méthodes alternatives pour faire face à diverses attaques. Ces méthodes nécessitaient que l'application s'engage dans certains protocoles de sécurité qui sont compliqués et peuvent être difficiles à mettre en œuvre. Par conséquent, il est plus simple de s'en remettre au protocole HTTPS pour la sécurité afin que les développeurs d'applications n'aient pas à s'en préoccuper.
Pour ce qui est de vos autres questions, la réponse dépend. Certains services ne veulent pas exiger l'utilisation de HTTPS, ont été développés avant OAuth 2, ou ont d'autres exigences qui peuvent les empêcher d'utiliser OAuth 2. En outre, le protocole OAuth 2 lui-même a fait l'objet de nombreux débats. Comme vous pouvez le constater, Facebook, Google et quelques autres ont tous mis en place des versions légèrement différentes de ce protocole. Certains s'en tiennent donc à OAuth 1 parce qu'il est plus uniforme sur les différentes plateformes. Récemment, le protocole OAuth 2 a été finalisé, mais nous devons encore voir comment son adoption se fera.
Notez qu'il existe de sérieux arguments de sécurité contre l'utilisation de Oauth 2 :
Notez que cela vient de l'auteur principal d'Oauth 2.
Points clés :
Oauth 2 n'offre aucune sécurité en plus de SSL, tandis que Oauth 1 est indépendant du transport.
Dans un sens, le SSL n'est pas sûr, car le serveur ne vérifie pas la connexion et les bibliothèques clientes courantes permettent d'ignorer facilement les échecs.
Le problème avec SSL/TLS, c'est que lorsque vous ne parvenez pas à vérifier le certificat du côté du client, la connexion fonctionne toujours. Chaque fois que le fait d'ignorer une erreur mène au succès, les développeurs vont faire exactement cela. Le serveur n'a aucun moyen d'imposer la vérification du certificat, et même s'il le pouvait, un attaquant ne le fera sûrement pas.
vous pouvez vous débarrasser de toute votre sécurité, ce qui est beaucoup plus difficile à faire dans OAuth 1.0 :
Les fautes de frappe constituent le deuxième problème potentiel. Considérez-vous que la conception est correcte lorsque l'omission d'un caractère (le "s" de "https") annule toute la sécurité du jeton ? Ou peut-être que l'envoi de la demande (via une connexion SSL/TLS valide et vérifiée) à la mauvaise destination (disons ' http://gacebook.com ' ?). Rappelez-vous, la possibilité d'utiliser les jetons de porteur OAuth à partir de la ligne de commande était clairement un cas d'utilisation que les défenseurs des jetons de porteur ont encouragé.
L'argument de la "faute de frappe" n'est pas très valable - il est courant de rediriger de http vers https.
@OlegMikheev Oui, mais il suffit d'une seule requête http (no-s) pour permettre à un MITM de renifler vos en-têtes et que votre jeton soit maintenant utilisé par quelqu'un d'autre !
Si par en-têtes vous voulez dire cookies, alors ils sont censés être sécurisé . En dehors de cela, je ne vois pas comment une erreur de frappe de l'utilisateur (dans l'URL du navigateur) peut exposer les tokens, ils ne sont même pas censés être dans les en-têtes.
Les signatures OAuth 2.0 ne sont pas requises pour les appels d'API proprement dits une fois que le jeton a été généré. Il n'y a qu'un seul jeton de sécurité.
OAuth 1.0 exige du client qu'il envoie deux jetons de sécurité pour chaque appel d'API et qu'il utilise les deux pour générer la signature. Il exige que les points de terminaison des ressources protégées aient accès aux informations d'identification du client afin de valider la demande.
Ici décrit la différence entre OAuth 1.0 et 2.0 et le fonctionnement des deux.
OAuth 2 est apparemment une perte de temps (de la bouche de quelqu'un qui y a été fortement impliqué) :
https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529
Il dit (édité pour la brièveté et en gras pour l'emphase) :
...je ne peux plus être associé à la norme OAuth 2.0. J'ai démissionné de mon rôle d'auteur principal auteur principal et éditeur, retiré mon nom de la spécification et quitté le groupe de travail. le groupe de travail. Retirer mon nom d'un document que j'ai j'ai laborieusement travaillé pendant trois ans et plus de deux douzaines de versions n'a pas été facile. Décider d'abandonner un effort que j'ai mené pendant plus de cinq ans cinq ans a été angoissante.
...A la fin, je suis arrivé à la conclusion que OAuth 2.0 est un mauvais protocole. WS-* mauvais. Il est suffisamment mauvais pour que je ne veuille plus être associé à ce protocole. ... Lorsque l'on compare avec OAuth 1.0, la spécification 2.0 spécification 2.0 est plus complexe, moins interopérable, moins utile, plus incomplète et, surtout, moins sûre.
Pour être clair, OAuth 2.0 à la main d'un développeur ayant une profonde compréhension de la sécurité du web aura probablement pour résultat une sécurisée. Cependant, entre les mains de la plupart des développeurs - comme cela a été l'expérience de ces deux dernières années - 2.0 est susceptible de produire des des implémentations non sécurisées.
Notez que les réponses par lien uniquement sont déconseillées, les références ayant tendance à se périmer avec le temps. Veuillez envisager d'ajouter un synopsis autonome ici, en conservant le lien comme référence.
La sécurité d'OAuth 1.0 repose sur l'hypothèse selon laquelle une clé secrète intégrée dans une application client peut rester confidentielle, mais cette hypothèse est naïve dans le cas des applications pour smartphones. Dans OAuth 2.0, une telle application cliente naïve est appelée client confidentiel . Il n'y a aucune différence pratique de niveau de sécurité entre les clients OAuth 1.0 et les clients confidentiels OAuth 2.0. "OAuth 2.0 et le chemin de l'enfer" passe à côté de ce point.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Vous pouvez trouver votre réponse ici OAuth 2.0 - Vue d'ensemble