En quoi OAuth 2 est-il différent de OAuth 1?
En termes très simples, quelqu'un peut-il expliquer la différence entre OAuth 2 et OAuth 1?
Est-ce que OAuth 1 est obsolète maintenant? Devrions-nous implémenter OAuth 2? Je ne vois pas beaucoup d'implémentations de OAuth 2; la plupart utilisent encore OAuth 1, ce qui me laisse douter que OAuth 2 est prêt à être utilisé. Est-ce
Eran Hammer-Lahav a fait un excellent travail en expliquant la plupart des différences dans son article Introducing OAuth 2. . Pour résumer, voici les principales différences:
Plus OAuth Flux permettant un meilleur support des applications non basées sur un navigateur. Il s'agit d'une critique majeure à l'encontre de OAuth. _ à partir d'applications clientes non basées sur un navigateur. Par exemple, dans OAuth 1.0, les applications de bureau ou de téléphonie mobile devaient obliger l'utilisateur à ouvrir son navigateur au service souhaité, à s'authentifier auprès du service et à copier le jeton du service dans l'application. La principale critique ici concerne l'expérience utilisateur. Avec OAuth 2.0, une application dispose désormais de nouveaux moyens d'obtenir une autorisation pour un utilisateur.
OAuth 2.0 n'exige plus que les applications clientes aient une cryptographie. Cela nous ramène à l'ancienne API Auth de Twitter, qui ne nécessitait pas l'application aux jetons de hachage HMAC. et demander des chaînes. Avec OAuth 2.0, l’application peut émettre une requête en utilisant uniquement le jeton émis sur HTTPS.
Les signatures OAuth 2.0 sont beaucoup moins compliquées. Plus besoin d'analyses, de tri ou d'encodages spéciaux.
OAuth 2.0 Les jetons d'accès sont "de courte durée". En règle générale, OAuth 1.0 Les jetons d'accès 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 qu’il s’agit, j’imagine 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 correspondre à la "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 chargé de traiter les demandes OAuth et le serveur gérant l'autorisation d'utilisateur. Plus d'informations à ce sujet sont détaillées dans l'article susmentionné.
Je vois d'excellentes réponses ici, mais ce qui me manque, ce sont des diagrammes et puisque j'ai dû 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 donc 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 s’appuyer uniquement sur HTTPS pour la sécurité afin que les développeurs d’applications n’aient pas à s’inquiéter.
En ce qui concerne vos autres questions, la réponse dépend. Certains services ne veulent pas exiger l’utilisation de HTTPS, ont été développés avant le OAuth 2, ou ont une autre exigence qui les empêcherait d’utiliser OAuth 2. De plus, de nombreux débat sur le protocole OAuth 2 lui-même. Comme vous pouvez le constater, Facebook, Google et quelques autres ont des versions légèrement différentes des protocoles mis en œuvre. Donc, certaines personnes restent avec OAuth 1 car il est plus uniforme sur les différentes plateformes. Récemment, le protocole OAuth 2 a été finalisé, mais nous n’avons pas encore annoncé son adoption.
Notez qu'il existe des arguments de sécurité sérieux contre l'utilisation de Oauth 2:
Notez qu'ils proviennent de l'auteur principal de Oauth 2.
Points clés:
Oauth 2 n'offre aucune sécurité sur SSL tandis que Oauth 1 est indépendant du transport.
en un sens, SSL n'est pas sécurisé car le serveur ne vérifie pas la connexion et les bibliothèques clientes communes facilitent l'ignorance des échecs.
Le problème avec SSL/TLS est que, lorsque vous ne parvenez pas à vérifier le certificat côté client, la connexion fonctionne toujours. Chaque fois que le fait d’ignorer une erreur conduit à la réussite, les développeurs vont le faire. Le serveur ne dispose d'aucun moyen pour imposer la vérification du certificat, et même s'il le pouvait, un attaquant ne le ferait sûrement pas.
vous pouvez supprimer 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 que cette conception est 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 (par exemple, " http://gacebook.com "?). N'oubliez pas que le fait de pouvoir utiliser OAuth jetons de la ligne de commande était clairement un cas d'utilisation préconisé par les défenseurs des jetons du porteur.
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 un client confidentiel . D'autre part, une application cliente dans un environnement où il est difficile de garder une clé secrète confidentielle s'appelle un client public . Voir 2.1. Types de clients pour plus de détails.
En ce sens, OAuth 1.0 est une spécification réservée aux clients confidentiels.
" OAuth 2.0 et la route de l'enfer " indique que OAuth 2.0 est moins sécurisé, mais il n'y a pas de différence pratique en termes de niveau de sécurité entre les clients OAuth 1.0 et OAuth 2.0 clients confidentiels. OAuth 1.0 requiert le calcul de la signature, mais 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 n’est qu’un calcul fastidieux sans amélioration pratique de la sécurité. Je veux dire, comparé à la simplicité avec laquelle un client OAuth 2.0 se connecte à un serveur via TLS et ne présente que _client_id_ et _client_secret_, on ne peut pas dire que le calcul fastidieux est plus efficace termes de sécurité.
En outre, RFC 5849 (OAuth 1.0) ne mentionne rien à propos de redirecteurs ouverts alors que RFC 6749 (OAuth 2.0) le fait. Cela signifie que le paramètre _oauth_callback_ de OAuth 1.0 peut devenir une faille de sécurité.
Par conséquent, je ne pense pas que OAuth 1.0 soit plus sûr que OAuth 2.0.
[14 avril 2016] Ajout pour clarifier mon propos
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. ). Toute personne connaissant la clé secrète peut calculer la signature. Ainsi, si la clé secrète est compromise, la complexité du calcul de signature n’a pas de 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 est uniquement la condition qu'une clé secrète puisse rester 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 OAuth 2.0 confidentiels dépendent de la même condition. Si la condition est déjà remplie, existe-t-il un problème pour créer une connexion sécurisée à l'aide de TLS et envoyer _client_id_ et 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 que OAuth 1.0 blâme OAuth 2.0. Le fait est simplement que (1) OAuth 1.0 n’est qu’une spécification destinée aux clients confidentiels et que (2) OAuth 2.0 a simplifié le protocole pour les clients confidentiels et pris en charge public , aussi. Que cela soit connu ou non, les applications pour smartphone sont classées comme clients publics ( RFC 6749, 9 ), qui bénéficient de OAuth 2.0.
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é pour la brièveté et en gras pour l'emphase):
... Je ne peux plus être associé à la norme OAuth 2.0. J'ai démissionné de mon rôle d'auteur principal et de rédacteur en chef, j'ai retiré mon nom de la spécification et quitté le groupe de travail. Retirer mon nom d'un document sur lequel je travaille péniblement depuis trois ans et plus de deux douzaines de brouillons n'a pas été facile. Décidant d'abandonner les efforts que je menais depuis plus de cinq ans, c'était angoissant.
... À la fin, j'ai conclu que OAuth 2.0 était un mauvais protocole. WS- * mauvais. C'est déjà assez que je ne veuille plus y être associé. ... 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 ayant une connaissance approfondie de la sécurité Web aura probablement pour résultat une implémentation sécurisée. Cependant, comme le montre l’expérience des deux dernières années, la plupart des développeurs ont tendance à penser que la version 2.0 produira probablement des implémentations peu sûres.
Les signatures OAuth 2.0 ne sont pas requises pour les appels d'API réels une fois le jeton généré. Il n'a qu'un seul jeton de sécurité.
OAuth 1.0 exige que le client envoie deux jetons de sécurité pour chaque appel d'API et les utilise pour générer la signature. Pour que la demande soit validée, les points d'extrémité des ressources protégées doivent avoir accès aux informations d'identification du client.
Ici décrit la différence entre OAuth 1.0 et 2.0 et leur fonctionnement.
Si vous avez besoin d'explications avancées, vous devez lire les deux spécifications:
Si vous avez besoin d’une explication claire des différences de débit, cela pourrait vous aider:
OAuth 1.0 Flow
- L'application client s'enregistre auprès du fournisseur, tel que Twitter.
- Twitter fournit au client un "secret du consommateur" propre à cette application.
- L'application cliente signe toutes les OAuth demandes à Twitter avec son unique "secret du consommateur".
- Si l'une des demandes OAuth est mal formée, si des données sont manquantes ou si elle est signée incorrectement, la demande sera rejetée.
OAuth 2.0 Flow
- L'application client s'enregistre auprès du fournisseur, tel que Twitter.
- Twitter fournit au client un "secret client" unique pour cette application.
- L'application client inclut "secret du client" avec chaque demande communément comme en-tête http.
- Si l'une des requêtes OAuth est malformée, contient des données manquantes ou contient un secret erroné, la requête sera rejetée.
OAuth 2.0 promet de simplifier les choses de la manière suivante:
- SSL est requis pour toutes les communications requises pour générer le jeton. Il s’agit d’une énorme diminution de complexité car ces signatures complexes ne sont plus nécessaires.
- 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.
- Une fois le jeton généré, OAuth 1.0 exige 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.
- 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. Il sera ainsi plus facile pour des produits comme Apigee d’offrir le support OAuth 2.0 aux API existantes.
Du point de vue de la sécurité, je choisirais OAuth 1. Voir OAuth 2.0 et la route de l'enfer
citation de ce lien: "Si vous utilisez actuellement la version 1.0 avec succès, ignorez la version 2.0. Elle n’offre aucune valeur réelle supérieure à la version 1.0 (je suppose que les développeurs de votre client ont déjà compris la signature 1.0 à ce jour).
Si vous débutez dans cet espace et que vous vous considérez comme un expert en sécurité, utilisez la version 2.0 après un examen minutieux de ses fonctionnalités. Si vous n’êtes pas un expert, utilisez la version 1.0 ou copiez l’implémentation 2.0 d’un fournisseur en lequel vous avez confiance, pour bien faire les choses (les documents de l’API de Facebook sont un bon point de départ). La version 2.0 est préférable pour les applications à grande échelle, mais si vous exécutez une opération importante, vous aurez probablement des experts en sécurité sur le site pour résoudre le problème à votre place. "