it-swarm.com.de

Inwiefern unterscheidet sich OAuth 2 von OAuth 1?

Kann jemand mit einfachen Worten den Unterschied zwischen OAuth 2 und OAuth 1 erklären?

Ist OAuth 1 jetzt veraltet? Sollten wir OAuth 2 implementieren? Ich sehe nicht viele Implementierungen von OAuth 2; Die meisten verwenden noch OAuth 1, weshalb ich bezweifle, dass OAuth 2 einsatzbereit ist. Ist es?

566
sullivan

Eran Hammer-Lahav hat die meisten Unterschiede in seinem Artikel hervorragend erklärt Einführung in OAuth 2. . Zusammenfassend sind hier die wichtigsten Unterschiede:

Mehr OAuth Fließt, um eine bessere Unterstützung für nicht browserbasierte Anwendungen zu ermöglichen. Dies ist eine Hauptkritik gegen OAuth. _ von Clientanwendungen, die nicht browserbasiert waren. In OAuth 1.0 mussten Desktopanwendungen oder Mobiltelefonanwendungen beispielsweise den Benutzer anweisen, den Browser für den gewünschten Dienst zu öffnen, sich beim Dienst zu authentifizieren und das Token vom Dienst zurück in die Anwendung zu kopieren. Die Hauptkritik ist hier gegen die User Experience. Mit OAuth 2.0 gibt es jetzt neue Möglichkeiten für eine Anwendung, die Autorisierung für einen Benutzer zu erhalten.

Für OAuth 2.0 ist keine Kryptografie mehr für Clientanwendungen erforderlich. Hierbei wird auf die alte Twitter-Authentifizierungs-API zurückgegriffen, für die die Anwendung für HMAC-Hashtoken nicht erforderlich war und fordere Strings an. Mit OAuth 2.0 kann die Anwendung nur unter Verwendung des über HTTPS ausgestellten Tokens eine Anforderung stellen.

OAuth 2.0-Signaturen sind wesentlich unkomplizierter. Keine weiteren speziellen Parsing-, Sortier- oder Codierungsschritte.

OAuth 2.0-Zugriffstoken sind "kurzlebig". In der Regel können OAuth 1.0-Zugriffstoken ein Jahr oder länger gespeichert werden. ( Twitter lässt sie niemals ablaufen). OAuth 2.0 hat den Begriff Aktualisierungstoken. Ich bin mir zwar nicht ganz sicher, was diese sind, aber ich vermute, dass Ihre Zugriffstoken von kurzer Dauer sein können (d. H. Sitzungsbasiert), während Ihre Aktualisierungstoken "lebenslang" sein können. Sie würden ein Aktualisierungstoken verwenden, um ein neues Zugriffstoken zu erhalten, anstatt dass der Benutzer Ihre Anwendung erneut autorisiert.

Schließlich soll mit OAuth 2.0 eine saubere Rollentrennung zwischen dem Server, der für die Verarbeitung von OAuth -Anforderungen verantwortlich ist, und dem Server, der die Benutzerberechtigung verarbeitet, hergestellt werden. Weitere Informationen dazu finden Sie im oben genannten Artikel.

499
villecoder

Ich sehe gute Antworten hier oben, aber was ich vermisse, waren einige Diagramme, und da ich mit Spring Framework arbeiten musste, bin ich auf ihre Erklärung gestoßen.

Ich finde die folgenden Diagramme sehr nützlich. Sie veranschaulichen den Unterschied in der Kommunikation zwischen Parteien mit OAuth2 und OAuth1.


OAuth 2

enter image description here


OAuth 1

enter image description here

177
nyxz

Die vorherigen Erklärungen sind allesamt zu detailliert und kompliziert, IMO. Einfach ausgedrückt delegiert OAuth 2 Sicherheit an das HTTPS-Protokoll. OAuth 1 erforderte dies nicht und verfügte folglich über alternative Methoden, um mit verschiedenen Angriffen umzugehen. Diese Methoden erforderten, dass die Anwendung bestimmte Sicherheitsprotokolle ausführt, die kompliziert und möglicherweise schwierig zu implementieren sind. Daher ist es einfacher, sich aus Sicherheitsgründen nur auf HTTPS zu verlassen, damit sich Anwendungsentwickler keine Sorgen machen müssen.

Was Ihre anderen Fragen betrifft, hängt die Antwort davon ab. Einige Dienste möchten nicht die Verwendung von HTTPS erfordern, wurden vor OAuth 2 entwickelt oder haben andere Anforderungen, die sie möglicherweise daran hindern, OAuth 2 zu verwenden. Darüber hinaus gab es eine Menge der Debatte über das OAuth 2-Protokoll selbst. Wie Sie sehen können, sind bei Facebook, Google und einigen anderen leicht unterschiedliche Versionen der Protokolle implementiert. Einige Leute bleiben also bei OAuth 1, weil es auf den verschiedenen Plattformen einheitlicher ist. Vor kurzem wurde das Protokoll OAuth 2 fertiggestellt, aber wir müssen noch abwarten, wie es angenommen wird.

83
chacham15

Beachten Sie, dass es ernsthafte Sicherheitsargumente gegen die Verwendung von Oauth 2 gibt:

ein trostloser Artikel

nd eine technischere

Beachten Sie, dass diese vom Hauptautor von Oauth 2 stammen.

Wichtige Punkte:

  • Oauth 2 bietet keine Sicherheit zusätzlich zu SSL, während Oauth 1 transportunabhängig ist.

  • in gewisser Hinsicht ist SSL nicht sicher, da der Server die Verbindung nicht überprüft und die allgemeinen Client-Bibliotheken das Ignorieren von Fehlern vereinfachen.

    Das Problem mit SSL/TLS besteht darin, dass die Verbindung weiterhin funktioniert, wenn Sie das Zertifikat auf der Clientseite nicht überprüfen können. Jedes Mal, wenn ein Fehler ignoriert wird, führt dies zum Erfolg. Die Entwickler werden genau das tun. Der Server hat keine Möglichkeit, die Zertifikatüberprüfung zu erzwingen, und selbst wenn dies möglich wäre, wird ein Angreifer dies sicherlich nicht tun.

  • in OAuth 1.0 können Sie Ihre gesamte Sicherheit in den Griff bekommen, was viel schwieriger zu bewerkstelligen ist:

    Das zweite häufige potenzielle Problem sind Tippfehler. Würden Sie es als angemessenes Design betrachten, wenn Sie ein Zeichen weglassen (das "s" in "https"), um die gesamte Sicherheit des Tokens aufzuheben? Oder senden Sie die Anfrage (über eine gültige und überprüfte SSL/TLS-Verbindung) an das falsche Ziel (sagen Sie " http://gacebook.com "?). Denken Sie daran, dass die Verwendung von OAuth Inhaber-Token über die Befehlszeile eindeutig ein Anwendungsfall war, für den Inhaber-Token befürwortet wurden.

34
djechlin

Die Sicherheit des Protokolls OAuth 1.0 ( RFC 5849 ) beruht auf der Annahme, dass ein in eine Clientanwendung eingebetteter geheimer Schlüssel vertraulich behandelt werden kann. Die Annahme ist jedoch naiv.

In OAuth 2.0 ( RFC 6749 ) wird eine solche naive Clientanwendung als vertraulicher Client bezeichnet. Andererseits wird eine Clientanwendung in einer Umgebung, in der es schwierig ist, einen geheimen Schlüssel geheim zu halten, als öffentlicher Client bezeichnet. Siehe 2.1. Client Types für Details.

In diesem Sinne ist OAuth 1.0 eine Spezifikation nur für vertrauliche Clients.

" OAuth 2.0 und der Weg zur Hölle " besagt, dass OAuth 2.0 weniger sicher ist, aber es gibt keinen praktischen Unterschied in der Sicherheitsstufe zwischen OAuth 1.0-Clients und OAuth 2.0 vertrauliche Clients. OAuth 1.0 erfordert die Berechnung der Signatur, erhöht jedoch nicht die Sicherheit, wenn bereits sichergestellt ist, dass ein geheimer Schlüssel auf der Clientseite vertraulich behandelt werden kann. Das Berechnen der Signatur ist nur eine umständliche Berechnung ohne praktische Sicherheitsverbesserung. Ich meine, verglichen mit der Einfachheit, dass ein OAuth 2.0-Client über TLS eine Verbindung zu einem Server herstellt und nur _client_id_ und _client_secret_ anzeigt, kann nicht gesagt werden, dass die umständliche Berechnung in besser ist Sicherheitsbestimmungen.

Darüber hinaus erwähnt RFC 5849 (OAuth 1.0) nichts über offene Redirectors , während RFC 6749 (OAuth 2.0) dies tut. Das heißt, der Parameter _oauth_callback_ von OAuth 1.0 kann zu einer Sicherheitslücke werden.

Daher glaube ich nicht, dass OAuth 1.0 sicherer ist als OAuth 2.0.


[14. April 2016] Ergänzung, um meinen Standpunkt zu verdeutlichen

Die OAuth 1.0-Sicherheit basiert auf der Signaturberechnung. Eine Signatur wird unter Verwendung eines geheimen Schlüssels berechnet, wobei ein geheimer Schlüssel ein gemeinsamer Schlüssel für HMAC-SHA1 ( RFC 5849, 3.4.2 ) oder ein privater Schlüssel für RSA-SHA1 ( RFC 5849) ist 3.4. ). Jeder, der den geheimen Schlüssel kennt, kann die Signatur berechnen. Wenn also der geheime Schlüssel kompromittiert wird, ist die Komplexität der Signaturberechnung bedeutungslos, wie komplex sie auch sein mag.

Dies bedeutet, dass die Sicherheit von OAuth 1.0 nicht von der Komplexität und Logik der Signaturberechnung abhängt, sondern lediglich von der Vertraulichkeit eines geheimen Schlüssels. Mit anderen Worten, was für die Sicherheit von OAuth 1.0 benötigt wird, ist nur die Bedingung, dass ein geheimer Schlüssel vertraulich behandelt werden kann. Dies mag extrem klingen, aber die Signaturberechnung bietet keine Sicherheitsverbesserung, wenn die Bedingung bereits erfüllt ist.

Ebenso verlassen sich OAuth 2.0 vertrauliche Clients auf dieselbe Bedingung. Wenn die Bedingung bereits erfüllt ist, besteht ein Problem beim Herstellen einer sicheren Verbindung mit TLS und beim Senden von _client_id_ und client_secret an ein Autorisierungsserver über die gesicherte Verbindung? Gibt es einen großen Unterschied in der Sicherheitsstufe zwischen OAuth 1.0 und OAuth 2.0 vertraulichen Clients, wenn beide auf denselben Bedingungen beruhen?

Ich kann keinen guten Grund für OAuth 1.0 finden, um OAuth 2.0 zu beschuldigen. Tatsache ist lediglich, dass (1) OAuth 1.0 nur eine Spezifikation für vertrauliche Clients ist und (2) OAuth 2.0 das Protokoll für vertrauliche Clients vereinfacht und unterstützt hat auch öffentliche Clients. Unabhängig davon, ob es bekannt ist oder nicht, werden Smartphone-Anwendungen als öffentliche Kunden ( RFC 6749, 9 ) eingestuft, die von OAuth 2.0 profitieren.

31

OAuth 2 ist anscheinend eine Zeitverschwendung (aus dem Mund von jemandem, der stark daran beteiligt war):

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

Er sagt (der Kürze halber bearbeitet und zur Hervorhebung fett gedruckt):

... Ich kann nicht mehr mit dem OAuth 2.0-Standard in Verbindung gebracht werden. Ich habe meine Rolle als Hauptautor und Herausgeber niedergelegt, meinen Namen aus der Spezifikation entfernt und die Arbeitsgruppe verlassen. Es war nicht einfach, meinen Namen aus einem Dokument zu entfernen, an dem ich drei Jahre lang mühsam gearbeitet habe, und über zwei Dutzend Entwürfe. Die Entscheidung, mich von einer Anstrengung zu lösen, die ich über fünf Jahre geführt habe, war qualvoll.

... Am Ende bin ich zu dem Schluss gekommen, dass OAuth 2.0 ein schlechtes Protokoll ist. WS- * schlecht. Es ist schon schlimm genug, dass ich nicht mehr damit in Verbindung gebracht werden will. ... Im Vergleich zu OAuth 1.0 ist die 2.0-Spezifikation komplexer, weniger interoperabel, weniger nützlich, unvollständiger und vor allem weniger sicher.

Um klar zu sein, OAuth 2.0 von einem Entwickler mit tiefem Verständnis der Websicherheit wird wahrscheinlich zu einer sicheren Implementierung führen. Aufgrund der Erfahrungen der meisten Entwickler in den letzten zwei Jahren ist es jedoch wahrscheinlich, dass 2.0 zu unsicheren Implementierungen führt.

21
Tony Knibb

OAuth 2.0-Signaturen sind für die tatsächlichen API-Aufrufe nicht erforderlich, sobald das Token generiert wurde. Es gibt nur ein Sicherheitstoken.

Für OAuth 1.0 muss der Client zwei Sicherheitstoken für jeden API-Aufruf senden und beide zum Generieren der Signatur verwenden. Es erfordert, dass die Endpunkte für geschützte Ressourcen Zugriff auf die Clientanmeldeinformationen haben, um die Anforderung zu validieren.

hier beschreibt den Unterschied zwischen OAuth 1.0 und 2.0 und wie beide funktionieren.

21
Fionaa Miller

Wenn Sie eine erweiterte Erklärung benötigen, müssen Sie beide Spezifikationen lesen:

https://oauth.net/core/1.0a/

https://oauth.net/2/

Wenn Sie eine klare Erklärung der Durchflussunterschiede benötigen, kann dies hilfreich sein:

OAuth 1.0 Flow

  1. Clientanwendung registriert sich beim Anbieter, z. B. Twitter.
  2. Twitter bietet dem Kunden ein für diese Anwendung einzigartiges "Verbrauchergeheimnis".
  3. Client App signiert alle OAuth Anfragen an Twitter mit sein einzigartiges "Verbrauchergeheimnis".
  4. Wenn eine der OAuth Anforderungen fehlerhaft ist, fehlende Daten enthält oder nicht ordnungsgemäß signiert wurde, wird die Anforderung abgelehnt.

OAuth 2.0 Flow

  1. Clientanwendung registriert sich beim Anbieter, z. B. Twitter.
  2. Twitter bietet dem Kunden ein "Kundengeheimnis", das nur für diese Anwendung gilt.
  3. Client-Anwendung enthält "Client-Geheimnis" mit Jede Anfrage wird üblicherweise als http-Header ausgegeben.
  4. Wenn eine der OAuth Anforderungen fehlerhaft ist, Daten fehlen oder das falsche Geheimnis enthält, wird die Anforderung abgelehnt.

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

9
JRichardsz

OAuth 2.0 verspricht, die Dinge auf folgende Weise zu vereinfachen:

  1. SSL ist für die gesamte Kommunikation erforderlich, die zum Generieren des Tokens erforderlich ist. Dies ist eine enorme Verringerung der Komplexität, da diese komplexen Signaturen nicht mehr erforderlich sind.
  2. Nach der Token-Generierung sind für die eigentlichen API-Aufrufe keine Signaturen mehr erforderlich - SSL wird auch hier dringend empfohlen.
  3. Nachdem das Token generiert wurde, musste OAuth 1.0, dass der Client bei jedem API-Aufruf zwei Sicherheitstoken sendet und beide verwendet, um die Signatur zu generieren. OAuth 2.0 verfügt nur über ein Sicherheitstoken, und es ist keine Signatur erforderlich.
  4. Es ist eindeutig festgelegt, welche Teile des Protokolls vom "Ressourcenbesitzer" implementiert werden. Dies ist der eigentliche Server, der die API implementiert, und welche Teile von einem separaten "Berechtigungsserver" implementiert werden können. Dies erleichtert es Produkten wie Apigee, vorhandene APIs mit OAuth 2.0 zu unterstützen.

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

7
Abhijit Gaikwad

Aus Sicherheitsgründen würde ich OAuth wählen. 1. Siehe OAuth 2.0 und der Weg zur Hölle

zitat aus diesem Link: "Wenn Sie derzeit 1.0 erfolgreich verwenden, ignorieren Sie 2.0. Es bietet keinen echten Wert über 1.0 (ich vermute, Ihre Client-Entwickler haben bereits 1.0-Signaturen herausgefunden).

Wenn Sie sich in diesem Bereich noch nicht auskennen und sich als Sicherheitsexperte betrachten, verwenden Sie 2.0, nachdem Sie die Funktionen sorgfältig geprüft haben. Wenn Sie kein Experte sind, verwenden Sie entweder 1.0 oder kopieren Sie die 2.0-Implementierung eines Anbieters, dem Sie vertrauen, um es richtig zu machen (die API-Dokumente von Facebook sind ein guter Ausgangspunkt). 2.0 ist besser für große Unternehmen, aber wenn Sie eine größere Operation ausführen, haben Sie wahrscheinlich einige Sicherheitsexperten vor Ort, um alles für Sie herauszufinden. "

1
harmv