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


604

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? Devrions-nous mettre en œuvre OAuth 2? Je ne vois pas beaucoup d'implémentations d'OAuth 2; la plupart utilisent encore OAuth 1, ce qui me fait douter qu'OAuth 2 est prêt à l'emploi. C'est ça?



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

Vous pouvez trouver votre réponse ici OAuth 2.0 - Présentation
John Joe

Réponses:


529

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. Il s'agit d'une critique principale contre OAuth provenant d'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 son navigateur sur le service souhaité, de s'authentifier auprès du service et de recopier le jeton du service vers l'application. La principale critique porte ici sur l'expérience utilisateur. Avec OAuth 2.0, il existe désormais de nouvelles façons pour une application d'obtenir l'autorisation d'un utilisateur.

OAuth 2.0 ne nécessite plus de cryptographie pour les applications clientes. Cela renvoie à l'ancienne API Twitter Auth, qui ne nécessitait pas l'application de jetons de hachage HMAC et de chaînes de demande. Avec OAuth 2.0, l'application peut effectuer une demande 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 spécial.

Les jetons d'accès OAuth 2.0 sont de "courte durée". 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 c'est, 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 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 demandes OAuth et le serveur gérant l'autorisation utilisateur. Plus d'informations à ce sujet sont détaillées dans l'article susmentionné.


2
Quelqu'un pourrait-il clarifier la différence entre les URL de rappel entre OAUTH 1 et 2?
Brian Armstrong

2
OAuth 2.0 ne supprimera OAuth que s'il est approuvé en tant que RFC. Actuellement, il s'agit d'un projet Internet, mais il est prévu de devenir un standard Internet (dans la mesure où ces choses peuvent être planifiées). Cependant, cela prendra des années, car de grandes parties du cadre ne sont pas encore spécifiées. Nous verrons probablement toute une famille de projets Internet publiés dans les années à venir, chacun concernant différents aspects du cadre d'autorisation OAuth 2.0. Pour voir pourquoi cela est vrai, visitez tools.ietf.org/html/draft-ietf-oauth-v2 , et recherchez «au-delà de la portée de cette spécification»;)
Håvard Geithus

48
L'auteur de l'article a écrit l'année dernière un suivi intitulé "OAuth 2.0 et la route de l'enfer", qui peut être lu ici: web.archive.org/web/20120731155632/http://hueniverse.com/2012/… Une différence significative entre les deux est la sécurité - comme le laisse présager le manque de cryptographie dans 2.0.
kdazzle

4
La sécurité d'OAuth 1.0 repose sur l'hypothèse qu'une clé secrète intégrée dans une application cliente peut rester confidentielle, mais l'hypothèse est naïve. Dans OAuth 2.0, une telle application client naïve est appelée client confidentiel . Il n'y a pas de 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 la route de l'enfer" manque ce point.
Takahiko Kawasaki

6
@kdazzle, ce lien est désormais déplacé ici: hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529
e_i_pi

193

Je vois de bonnes réponses ici, mais ce qui me manque, ce sont quelques diagrammes et comme je devais travailler 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

entrez la description de l'image ici


OAuth 1

entrez la description de l'image ici


3
où "client_secret" est-il utilisé dans ce flux ??
ashwintastic

3
Si vous voulez dire le secret que l'utilisateur entre lorsqu'il est redirigé vers le fournisseur (disons Facebook, Twitter, Google, etc.), ce serait l'étape 2 OAuth 2et l'étape 4 OAuth 1.
nyxz

Pourquoi les deux diagrammes comportent-ils une étape de fournisseur de services appelée "Autorisation des autorisations utilisateur?" Cela semble en arrière ou faux. "L'utilisateur" n'est-il pas celui qui demande l'autorisation?
Forbin

@Forbin Parce que cette étape se produit du côté du fournisseur de services. Vous êtes sur leur page où vous voyez les subventions que le service exige de vous et vous devez accepter de partager ces informations avec le service auquel vous essayez de vous authentifier. StackOverflow a en fait la possibilité de se connecter en utilisant un compte Google. Cela fonctionne de la même manière. SO demandera à Google de consulter votre e-mail et vous devez vous mettre d'accord.
nyxz

92

Les explications précédentes sont toutes trop détaillées et compliquées OMI. En termes simples, 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 simplement compter sur le 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 exiger l'utilisation de HTTPS, ont été développés avant OAuth 2, ou ont une autre exigence qui peut 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. Certaines personnes s'en tiennent donc à OAuth 1 car il est plus uniforme sur les différentes plates-formes. Récemment, le protocole OAuth 2 a été finalisé mais nous n'avons pas encore vu comment son adoption se déroulera.


11
Donc, fondamentalement, OAuth2 fonctionne avec HTTPS et est donc plus simple que OAuth1 qui doit être un peu plus complexe car il peut fonctionner sans HTTPS?
Micro

@MicroR Voici une définition pratique que vous avez trouvée là-bas! ;)
EralpB

36

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

un article sombre

et 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 qu'Oauth 1 est indépendant du transport.

  • en un sens, SSL n'est pas sécurisé dans la mesure où le serveur ne vérifie pas la connexion et les bibliothèques clientes communes permettent d'ignorer facilement les é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 ignorer une erreur mène au succès, les développeurs vont le faire. Le serveur n'a aucun moyen d'appliquer la vérification des certificats, et même s'il le pouvait, un attaquant ne le fera sûrement pas.

  • vous pouvez effacer 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érez-vous qu'il s'agit d'une conception appropriée lorsque l'omission d'un caractère (le «s» dans «https») annule la sécurité totale du jeton? Ou peut-être envoyer la demande (via une connexion SSL / TLS valide et vérifiée) à la mauvaise destination (dites « http://gacebook.com »?). Rappelez-vous que pouvoir utiliser des jetons de porteur OAuth à partir de la ligne de commande était clairement un argument de promotion des jetons de porteur de cas d'utilisation.


4
l'argument "faute de frappe" n'est pas très valable - il est courant de rediriger de http vers https
Oleg Mikheev

2
@OlegMikheev Oui, mais il suffit d'une seule requête http (no-s) pour permettre à un MITM de flairer vos en-têtes et votre token est maintenant utilisé par quelqu'un d'autre!
Patrick James McDougle

3
si par en-têtes vous entendez des cookies, ils sont censés être sécurisés . En dehors de cela, je ne vois pas comment la faute de frappe de l'utilisateur (dans l'URL du navigateur) peut exposer des jetons, ils ne sont même pas censés être dans les en
Oleg Mikheev

2
En tant que point supplémentaire contre l'argument "typo", un fournisseur de services peut rejeter toutes les demandes OAuth 2.0 qui ne passent pas par https et révoquer le jeton d'accès dans cette demande.
skeller88

32

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 telle application client naïve est appelée client confidentiel . En revanche, une application cliente dans un environnement où il est difficile de garder une clé secrète confidentielle est appelée 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.

« OAuth 2.0 et la route de l'enfer » indique qu'OAuth 2.0 est moins sécurisé, mais il n'y a pas de différence pratique 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 il n'améliore pas la sécurité s'il est déjà assuré qu'une clé secrète côté client peut être gardée confidentielle. Le calcul de la signature n'est qu'un calcul fastidieux sans aucune amélioration pratique de la sécurité. Je veux dire, par rapport à la simplicité qu'un client OAuth 2.0 se connecte à un serveur via TLS et présente simplement client_idet client_secret, on ne peut pas dire que le calcul encombrant est meilleur en termes de sécurité.

De plus, la RFC 5849 (OAuth 1.0) ne mentionne rien sur les redirecteurs ouverts, contrairement à la RFC 6749 (OAuth 2.0). Autrement dit, le oauth_callbackparamètre d'OAuth 1.0 peut devenir une faille de sécurité.

Par conséquent, je ne pense pas qu'OAuth 1.0 soit plus sûr qu'OAuth 2.0.


[14 avril 2016] Ajout pour clarifier mon point

La sécurité OAuth 1.0 repose sur le calcul des signatures. Une signature est calculée à l'aide d'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 ). Quiconque connaît la clé secrète peut calculer la signature. Donc, si la clé secrète est compromise, la complexité du calcul de la signature n'a aucun sens, quelle que soit sa complexité.

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 n'est que la condition qu'une clé secrète puisse être gardée confidentielle. Cela peut sembler extrême, mais le calcul de la signature n'ajoute aucune amélioration de la sécurité si la condition est déjà remplie.

De même, les clients confidentiels OAuth 2.0 s'appuient sur la même condition. Si la condition est déjà remplie, y a-t-il un problème à créer une connexion sécurisée à l'aide de TLS et à envoyer client_idet client_secretà un serveur d'autorisation via la connexion sécurisée? Existe-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 trouve aucune bonne raison pour qu'OAuth 1.0 blâme OAuth 2.0. Le fait est simplement que (1) OAuth 1.0 n'est qu'une spécification uniquement pour les clients confidentiels et (2) OAuth 2.0 a également simplifié le protocole pour les clients confidentiels et les clients publics pris en charge . Qu'elles soient bien connues ou non, les applications pour smartphones sont classées comme clients publics ( RFC 6749, 9 ), qui bénéficient d'OAuth 2.0.


7
L'envoi de secrets au lieu de signatures, que ce soit via HTTP, HTTPS, etc., comportera toujours un risque de sécurité implicite en raison du MITM au niveau du protocole. Il y a maintenant 2 façons de trouver des secrets au lieu d'une seule: rooter l'appareil ou forger des certificats racine (c'est déjà arrivé, donc pas farfelu). Lorsque votre modèle de sécurité est "eh, laissez le transport le gérer", il est vrai qu'il ne sera PAS MOINS sûr que le protocole. Mais les modèles de sécurité monolithiques == un point d'entrée pour de nombreux services. Il est "assez bon" pour les ingénieurs pragmatiques, mais il ne sera jamais "aussi sûr" qu'un modèle décentralisé alternatif.
Mark G.18

23

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 nécessite que le client envoie deux jetons de sécurité pour chaque appel d'API et les utilise pour générer la signature. Il 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.

Voici la différence entre OAuth 1.0 et 2.0 et comment les deux fonctionnent.


22

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

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

Il dit (édité par souci de concision et mis en gras pour souligner):

... Je ne peux plus être associé au standard 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 quitté le groupe de travail. Supprimer mon nom d'un document que j'ai laborieusement travaillé pendant trois ans et plus de deux douzaines de brouillons n'a pas été facile. Décider de passer d'un effort que je mène depuis plus de cinq ans était angoissant.

... À la fin, je suis arrivé à la conclusion que OAuth 2.0 est un mauvais protocole. WS- * mauvais. C'est déjà assez grave pour que je ne veuille plus y être associé. ... Par rapport à OAuth 1.0, la 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 par un développeur ayant une compréhension approfondie de la sécurité Web se traduira probablement par une implémentation sécurisée. Cependant, aux mains 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 des implémentations non sécurisées.


7
Notez que les réponses de lien uniquement sont déconseillées, les références ont tendance à devenir obsolètes au fil du temps. Veuillez envisager d'ajouter un synopsis autonome ici, en conservant le lien comme référence.
kleopatra

6
La sécurité d'OAuth 1.0 repose sur l'hypothèse qu'une clé secrète intégrée dans une application cliente peut être gardée confidentielle, mais l'hypothèse est naïve dans le cas des applications pour smartphone. Dans OAuth 2.0, une telle application client naïve est appelée client confidentiel . Il n'y a pas de 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 la route de l'enfer" manque ce point.
Takahiko Kawasaki

15

Si vous avez besoin d'explications avancées, 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 flux, 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 consommation» unique à cette application.
  3. L'application cliente signe toutes les demandes OAuth à Twitter avec son «secret du consommateur» unique .
  4. Si l'une des demandes OAuth est mal formée, manque des données ou est signée de manière incorrecte, 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. L'application client comprend un «secret client» avec chaque requête communément appelée en-tête http.
  4. Si l'une des demandes OAuth est mal formé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/


2
Pouvez-vous voir les signes en gras? Peut-être que fonctionnel pourrait avoir le même concept mais, techniquement parlant, utilisez un simple en- tête (oauth2), c'est très différent de signer la demande entière. Faites attention et d' améliorer votre compréhension de lecture avant les réponses comme marque pas utile
JRichardsz

1
veuillez lire votre propre réponse et essayer de la comprendre. «Signe toutes les demandes avec secret» et «envoie des secrets avec toutes les demandes». Personne sain d'esprit ne comprendra la différence ici à moins qu'il ne l'ait déjà utilisé. Je connais la différence mais pas l'OP. Cette réponse ne fera qu'embrouiller OP, d'où les votes négatifs. Ces réponses vagues méritent un vote négatif. Veuillez lire d'autres réponses ici qui sont beaucoup plus spécifiques et informatives.
saran3h

12 développeurs l'ont compris. oauth1 et oauth2 ont de nombreuses différences. Les réponses précédentes les couvrent et comme je l'ai dit , vous pouvez lire ce oauth.net/core/1.0a ou ce oauth.net/2 pour faire votre propre réponse. Mon objectif est de montrer l'une des différences techniques les plus notoires lorsqu'un développeur doit développer un client de repos.
JRichardsz

7

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. Il s'agit d'une énorme diminution de la complexité, car ces signatures complexes ne sont plus nécessaires.
  2. Les signatures ne sont pas requises pour les appels d'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 les utilise 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 à des produits comme Apigee de proposer plus facilement le support OAuth 2.0 aux API existantes.

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


1

Du point de vue de la sécurité, je choisirais OAuth 1. Voir OAuth 2.0 et la route de l'enfer

citez ce lien: "Si vous utilisez actuellement 1.0 avec succès, ignorez 2.0. Il n'offre aucune valeur réelle par rapport à 1.0 (je suppose que vos développeurs clients ont déjà compris 1.0 signatures à ce jour).

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.