tutorial - oauth2 wiki




En quoi OAuth 2 est-il différent d'OAuth 1? (8)

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?


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.


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é.


La 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 client aussi naïve est appelée un client confidentiel . D'autre part, une application cliente dans un environnement où il est difficile de garder une clé secrète confidentielle est appelée un client public . 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.

" hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell " indique que 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 OAuth 2.0 confidentiels. OAuth 1.0 nécessite de calculer la signature, mais il n'améliore pas la sécurité s'il est déjà assuré qu'une clé secrète côté client peut rester confidentielle. La signature informatique est juste un calcul lourd sans aucune amélioration de sécurité pratique. Je veux dire, comparé à la simplicité qu'un client OAuth 2.0 se connecte à un serveur sur TLS et présente simplement client_id et client_secret , on ne peut pas dire que le calcul fastidieux soit meilleur en termes de sécurité.

En outre, la RFC 5849 (OAuth 1.0) ne mentionne rien sur les redirecteurs ouverts, contrairement au RFC 6749 (OAuth 2.0). Autrement dit, le paramètre oauth_callback de OAuth 1.0 peut devenir un trou de sécurité.

Par conséquent, je ne pense pas OAuth 1.0 est plus sûr 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 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, les clients confidentiels OAuth 2.0 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 de client_id et de 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 dépendent de 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 est juste une spécification uniquement pour les clients confidentiels et (2) OAuth 2.0 a simplifié le protocole pour les clients confidentiels et les clients publics pris en charge, aussi. Qu'elles soient connues ou non, les applications smartphone sont classées en tant que clients publics ( RFC 6749, 9 ), qui bénéficient d'OAuth 2.0.


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.


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.


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