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? 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?

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

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

OAuth 1

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.

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.

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.

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.

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.

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.

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/

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

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