Question En quoi OAuth 2 est-il différent d'OAuth 1?


En termes très simples, quelqu'un peut-il expliquer la différence entre OAuth 2 et OAuth 1?

OAuth 1 est-il obsolète maintenant? Devrait être l'implémentation d'OAuth 2? Je ne vois pas beaucoup d'implémentations de OAuth 2; la plupart utilisent toujours OAuth 1, ce qui me fait douter que OAuth 2 soit prêt à l'emploi. Est-ce?


506
2017-11-06 16:18


origine


Réponses:


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.  Ceci est une critique principale contre OAuth des applications clientes qui n'étaient pas basées sur un navigateur. Par exemple, dans OAuth 1.0, les applications de bureau ou les applications de téléphonie mobile devaient demander à l'utilisateur d'ouvrir leur navigateur sur le service souhaité, de s'authentifier auprès du service et de copier le jeton du service vers l'application. La principale critique est contre l'expérience utilisateur. Avec OAuth 2.0, il existe maintenant de nouvelles façons pour une application d'obtenir une autorisation pour un utilisateur.

OAuth 2.0 ne nécessite plus de cryptographie pour les applications client.  Cela nous ramène à l'ancienne API d'Auth Twitter, qui ne nécessitait pas l'application pour les jetons de hachage HMAC et les chaînes de requête. Avec OAuth 2.0, l'application peut effectuer une requête en utilisant uniquement le jeton émis via HTTPS.

Les signatures OAuth 2.0 sont beaucoup moins compliquées. Plus d'analyse, de tri ou d'encodage.

OAuth 2.0 Les jetons d'accès sont "éphémères". En règle générale, 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 d'actualisation. Bien que je ne sois pas tout à fait sûr de ce que ce sont, je suppose que vos jetons d'accès peuvent être de courte durée (c'est-à-dire basés sur une session) alors que vos jetons de rafraîchissement peuvent être "durée de vie". Vous utiliseriez un jeton d'actualisation 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é avoir une séparation nette des rôles entre le serveur responsable de la gestion des requêtes OAuth et le serveur gérant les autorisations des utilisateurs.  Plus d'informations à ce sujet sont détaillées dans l'article susmentionné.


448
2017-11-08 17:02



Je vois de bonnes réponses ici, mais ce qui me manque, c’est des diagrammes et depuis que je travaille avec Spring Framework, je suis tombé sur leur explication.

Je trouve les diagrammes suivants très utiles. Ils illustrent la différence de communication entre les parties avec OAuth2 et OAuth1.


OAuth 2

enter image description here


Vérité 1

enter image description here


146
2017-12-13 12:32



Les explications précédentes sont toutes trop détaillées et compliquées IMO. En d'autres termes, OAuth 2 délègue la sécurité au protocole HTTPS. OAuth 1 ne l'exigeait pas et avait par conséquent des 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 se fier uniquement au protocole HTTPS pour la sécurité afin que les développeurs d'applications n'aient pas à s'en soucier.

Quant à vos autres questions, la réponse dépend. Certains services ne veulent pas nécessiter 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, il y a eu beaucoup de débats sur le protocole OAuth 2 lui-même. Comme vous pouvez le voir, Facebook, Google et quelques autres ont chacun des versions légèrement différentes des protocoles mis en œuvre. Donc certaines personnes s'en tiennent à OAuth 1 parce que c'est plus uniforme sur les différentes plateformes. Récemment, le protocole OAuth 2 a été finalisé mais nous n'avons pas encore vu comment son adoption va prendre.


76
2017-10-30 19:00



Notez qu'il existe des arguments de sécurité sérieux contre l'utilisation d'Oauth 2:

un article sombre

et un plus technique

Notez que ceux-ci proviennent de l'auteur principal de Oauth 2.

Points clés:

  • Oauth 2 n'offre aucune sécurité au-dessus de SSL tandis que Oauth 1 est indépendant du transport.

  • Dans un sens, SSL n'est pas sécurisé car le serveur ne vérifie pas la connexion et les bibliothèques client communes facilitent l'ignorance des échecs.

    Le problème avec SSL / TLS, c'est que lorsque vous ne parvenez pas à vérifier le certificat côté client, la connexion fonctionne toujours. Chaque fois que l'on oublie une erreur, les développeurs vont le faire. Le serveur n'a aucun moyen d'imposer la vérification des certificats, et même si cela est possible, un attaquant ne le fera sûrement pas.

  • vous pouvez éliminer toute votre sécurité, ce qui est beaucoup plus difficile à faire dans OAuth 1.0:

    Le deuxième problème potentiel commun est la faute de frappe. Considéreriez-vous cela comme un bon design en omettant un caractère (le 's' dans 'https') annule la sécurité entière du jeton? Ou peut-être envoyer la demande (via une connexion SSL / TLS valide et vérifiée) à la mauvaise destination (par exemple 'http://gacebook.com'?). Rappelez-vous, être capable d'utiliser des jetons de porteur OAuth depuis la ligne de commande était clairement un cas d'utilisation promu par les partisans des jetons.


27
2018-03-01 22:04



Les signatures OAuth 2.0 ne sont pas requises pour les appels d'API réels une fois que le jeton a été généré. Il n'a qu'un seul jeton de sécurité.

OAuth 1.0 requiert que le client envoie deux jetons de sécurité pour chaque appel API et utilise les deux pour générer la signature. Elle requiert 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 comment les deux fonctionnent.


21
2018-01-09 06:02



Sécurité du protocole OAuth 1.0 (RFC 5849) repose sur l'hypothèse qu'une clé secrète intégrée dans une application cliente peut rester confidentielle. Cependant, l'hypothèse est naïve.

Dans OAuth 2.0 (RFC 6749), une application cliente si naïve est appelée confidentiel client. D'autre part, une application cliente dans un environnement où il est difficile de garder une clé secrète confidentielle est appelée Publique client. Voir 2.1. Types de clients pour plus de détails.

En ce sens, OAuth 1.0 est une spécification uniquement pour les clients confidentiels.

"OAuth 2.0 et la route vers l'enfer"OAuth 2.0 est moins sécurisé, mais il n'y a pas de différence de niveau de sécurité entre les clients OAuth 1.0 et les clients confidentiels OAuth 2.0. OAuth 1.0 nécessite de calculer la signature, mais n'améliore pas la sécurité s'il est déjà assuré qu'une clé secrète La signature informatique est juste un calcul fastidieux sans aucune amélioration pratique de la sécurité, comparé à la simplicité qu'un client OAuth 2.0 se connecte à un serveur via TLS et se contente de présenter client_id et client_secret, on ne peut pas dire que le calcul encombrant est meilleur en termes de sécurité.

En outre, RFC 5849 (OAuth 1.0) ne mentionne rien à propos de redirecteurs ouverts tandis que RFC 6749 (OAuth 2.0) le fait. C'est, oauth_callback paramètre de OAuth 1.0 peut devenir un trou de sécurité.

Par conséquent, je ne pense pas que OAuth 1.0 soit plus sécurisé que OAuth 2.0.


[14 avril 2016] Ajout pour clarifier mon point

La sécurité OAuth 1.0 repose sur le calcul de la signature. Une signature est calculée en utilisant une clé secrète où une clé secrète est une clé partagée pour HMAC-SHA1 (RFC 5849, 3.4.2) ou une clé privée pour RSA-SHA1 (RFC 5849, 3.4.3). Toute personne connaissant la clé secrète peut calculer la signature. Ainsi, si la clé secrète est compromise, la complexité du calcul de la signature est dénuée de sens, même si elle est complexe.

Cela signifie que la sécurité OAuth 1.0 ne repose pas sur la complexité et la logique du calcul de la signature, mais simplement sur la confidentialité d'une clé secrète. En d'autres termes, ce qui est nécessaire pour la sécurité OAuth 1.0 est seulement la condition qu'une clé secrète puisse être gardée confidentielle. Cela peut sembler extrême, mais le calcul de signature n'ajoute aucune amélioration de sécurité si la condition est déjà satisfaite.

De même, OAuth 2.0 confidentiel les clients dépendent de la même condition. Si la condition est déjà remplie, y a-t-il un problème lors de la création d'une connexion sécurisée à l'aide de TLS et de l'envoi client_id et client_secret à un serveur d'autorisation via la connexion sécurisée? Y a-t-il une grande différence de niveau de sécurité entre les clients confidentiels OAuth 1.0 et OAuth 2.0 si les deux reposent sur la même condition?

Je ne peux pas trouver de bonnes raisons pour OAuth 1.0 de blâmer OAuth 2.0. Le fait est simplement que (1) OAuth 1.0 n'est qu'une spécification pour les clients confidentiels et (2) OAuth 2.0 a simplifié le protocole pour les clients confidentiels et pris en charge. Publique les clients aussi. Qu'elles soient connues ou non, les applications pour smartphones sont classées comme clients publics (RFC 6749, 9), qui bénéficient de OAuth 2.0.


19
2018-03-03 14:34



OAuth 2 est apparemment une perte de temps (de la bouche de quelqu'un qui était 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 mettre l'accent):

... je ne peux plus être   associé à la norme OAuth 2.0. J'ai démissionné de mon rôle de chef de file   auteur et éditeur, retirer mon nom de la spécification, et à gauche   le groupe de travail. Retirer mon nom d'un document que j'ai   laborieusement travaillé pendant trois ans et plus de deux douzaines de projets   n'était pas facile Décider de passer d'un effort que j'ai mené pour plus de   cinq ans était douloureux.

... À la fin, je suis arrivé à la conclusion que OAuth 2.0 est un mauvais   protocole. WS- * mauvais C'est déjà assez grave que je ne veuille plus être   associé avec. ... En comparaison avec OAuth 1.0, le 2.0   la spécification est plus complexe, moins interopérable, moins utile, plus   incomplet, et surtout, moins sûr.

Pour être clair, OAuth 2.0 à la main d'un développeur avec des profondeurs   la compréhension de la sécurité Web entraînera probablement une sécurité   la mise en oeuvre. Cependant, de la part de la plupart des développeurs - comme cela a été   l'expérience des deux dernières années - 2.0 est susceptible de produire   implémentations non sécurisées.


19
2018-06-28 11:59



OAuth 2.0 promet de simplifier les choses de la manière suivante:

  1. SSL est requis pour toutes les communications requises pour générer le jeton. Ceci réduit considérablement la complexité car ces signatures complexes ne sont plus nécessaires.
  2. Les signatures ne sont pas requises pour les appels API réels une fois le jeton généré - SSL est également fortement recommandé ici.
  3. Une fois le jeton généré, OAuth 1.0 exigeait que le client envoie deux jetons de sécurité à chaque appel d'API et utilisait les deux pour générer la signature. OAuth 2.0 n'a qu'un seul jeton de sécurité et aucune signature n'est requise.
  4. Il est clairement spécifié quelles parties du protocole sont implémentées par le «propriétaire de la ressource», qui est le serveur réel qui implémente l'API, et quelles parties peuvent être implémentées par un «serveur d'autorisation» distinct. Cela permettra aux produits comme Apigee d’offrir plus facilement la prise en charge d’OAuth 2.0 aux API existantes.

La source:http://blog.apigee.com/detail/oauth_differences


6
2018-03-14 05:14



Si vous avez besoin d'une explication avancée, vous devez lire les deux spécifications:

https://oauth.net/core/1.0a/

https://oauth.net/2/

Si vous avez besoin d'une explication claire des différences de débit, cela pourrait vous aider:

Flux OAuth 1.0

  1. L'application cliente s'enregistre auprès d'un fournisseur, tel que Twitter.
  2. Twitter fournit au client un «secret de consommateur» unique à cette application.
  3. Application client signes toutes les requêtes OAuth sur Twitter avec son unique "Secret du consommateur".
  4. Si une requête OAuth est mal formée, manque des données ou est incorrectement signée, la demande sera rejetée.

Flux OAuth 2.0

  1. L'application cliente s'enregistre auprès d'un fournisseur, tel que Twitter.
  2. Twitter fournit au client un "secret client" unique à cette application.
  3. Application client inclut  "Secret client" avec chaque demande.
  4. Si une requête OAuth est malformée, manque des données ou contient un mauvais secret, la demande sera rejetée.

La source : https://codiscope.com/oauth-2-0-vs-oauth-1-0/


3
2018-04-10 14:40