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




oauth2 wiki (9)

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 d'OAuth 2; la plupart utilisent toujours OAuth 1, ce qui me fait douter que OAuth 2 soit prêt à l'emploi. Est-ce?


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 client s'enregistre auprès du fournisseur, tel que Twitter.
  2. Twitter fournit au client un «secret de consommateur» unique à cette application.
  3. L'application client signe toutes les demandes OAuth sur Twitter avec son "secret client" unique .
  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 client s'enregistre auprès du fournisseur, tel que Twitter.
  2. Twitter fournit au client un "secret client" unique à cette application.
  3. L'application client inclut "secret client" à 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.

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


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.

Here décrit la différence entre OAuth 1.0 et 2.0 et comment les deux fonctionnent.


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

hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

et un plus technique

Notez que ceux-ci proviennent de l'auteur principal d'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 sont les fautes 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.


Du point de vue de la sécurité, j'opterais pour OAuth 1. Voir OAuth 2.0 et la route vers l'enfer

citation de ce lien: "Si vous utilisez actuellement la version 1.0, ignorer la version 2.0, elle n'a pas de valeur réelle supérieure à 1.0 (je suppose que vos développeurs clients ont déjà compris 1.0 signatures maintenant).

Si vous êtes nouveau dans cet espace et que vous vous considérez comme un expert en sécurité, utilisez la version 2.0 après un examen attentif de ses fonctionnalités. Si vous n'êtes pas un expert, utilisez soit la version 1.0, soit copiez l'implémentation 2.0 d'un fournisseur en qui vous avez confiance pour bien faire les choses (les documents API de Facebook sont un bon point de départ). 2.0 est meilleur pour une grande échelle, mais si vous exécutez une opération majeure, vous avez probablement des experts en sécurité sur place pour tout comprendre.


Je vois de bonnes réponses ici, mais ce qui me manque, ce sont des diagrammes et puisque j'ai dû travailler avec Spring Framework, j'ai trouvé 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

OAuth 1


OAuth 2 est apparemment une perte de temps (de la bouche de quelqu'un qui était fortement impliqué):

hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

Il dit (édité pour la brièveté et en caractères gras pour souligner):

... Je ne peux plus être associé à la norme OAuth 2.0. J'ai démissionné de mon rôle d'auteur principal et d'éditeur, retiré mon nom du cahier des charges et j'ai quitté le groupe de travail. Retirer mon nom d'un document que j'ai travaillé minutieusement pendant trois ans et plus de deux douzaines de brouillons n'a pas été facile. Décider de poursuivre un effort que j'ai mené pendant plus de cinq ans a été angoissant.

... À la fin, j'ai conclu que OAuth 2.0 est un mauvais protocole. WS- * mauvais. C'est assez mauvais que je ne veux plus être associé à cela. ... Comparée à OAuth 1.0, la spécification 2.0 est plus complexe, moins interopérable, moins utile, plus incomplète et, surtout, moins sécurisée.

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


Si vous voulez voir une explication concise et un flux détaillé (avec des diagrammes) d'OAuth, vous pouvez consulter http://oauthbible.com


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 que le jeton a été 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 facilitera la prise en charge d'OAuth 2.0 par des produits comme Apigee pour les API existantes.

Source: http://blog.apigee.com/detail/oauth_differences


Eran Hammer-Lahav a fait un excellent travail en expliquant la majorité des différences dans son article Introducing 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 client 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 ordonner à l'utilisateur d'ouvrir son navigateur au service souhaité, de s'authentifier auprès du service et de copier le jeton du service dans l'application. La principale critique ici est contre l'expérience de l'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 revient à l'ancienne API Twitter Auth, qui ne nécessitait pas l'application aux jetons de hachage HMAC et aux 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 cela représente, 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 d'actualisation peuvent être "à 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 destiné à avoir une séparation nette des rôles entre le serveur chargé de gérer les requêtes OAuth et le serveur gérant l'autorisation de l'utilisateur. Plus d'informations à ce sujet sont détaillées dans l'article précité.