Wie unterscheidet sich OAuth 2 von OAuth 1?

Kann jemand in sehr 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 immer noch OAuth 1, was mich bezweifeln lässt, dass OAuth 2 einsatzbereit ist. Ist es?

Eran Hammer-Lahav hat die meisten Unterschiede in seinem Artikel Introducing OAuth 2.0 hervorragend erklärt . Zusammenfassend sind hier die wichtigsten Unterschiede:

Mehr OAuth-Flows für eine bessere Unterstützung von nicht browserbasierten Anwendungen. Dies ist eine Hauptkritik gegen OAuth von Clientanwendungen, die nicht browserbasiert waren. In OAuth 1.0 mussten Desktop- oder Mobiltelefonanwendungen den Benutzer beispielsweise anweisen, seinen 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 hier ist gegen die Benutzererfahrung. 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 müssen Clientanwendungen nicht mehr über Kryptografie verfügen. Dies führt auf die alte Twitter-Auth-API zurück, für die keine Anwendung auf HMAC-Hash-Token und Anforderungszeichenfolgen erforderlich war. Mit OAuth 2.0 kann die Anwendung eine Anforderung nur mit dem über HTTPS ausgestellten Token stellen.

OAuth 2.0-Signaturen sind viel weniger kompliziert. Kein spezielles Parsen, Sortieren oder Codieren mehr.

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 der Aktualisierungstoken. Ich bin mir zwar nicht ganz sicher, was das ist, aber ich vermute, dass Ihre Zugriffstoken nur von kurzer Dauer sein können (dh sitzungsbasiert), während Ihre Aktualisierungstoken "Lebenszeit" sein können. Sie würden ein Aktualisierungstoken verwenden, um ein neues Zugriffstoken zu erhalten, anstatt den Benutzer Ihre Anwendung erneut autorisieren zu lassen.

Schließlich soll 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, haben. Weitere Informationen hierzu finden Sie im oben genannten Artikel.

Ich sehe hier oben großartige Antworten, aber was ich vermisse, sind einige Diagramme, und da ich mit Spring Framework arbeiten musste, bin ich auf deren 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

OAuth 1

Die vorherigen Erklärungen sind alle zu detailliert und kompliziert IMO. Einfach ausgedrückt delegiert OAuth 2 die Sicherheit an das HTTPS-Protokoll. OAuth 1 benötigte dies nicht und verfügte folglich über alternative Methoden, um mit verschiedenen Angriffen umzugehen. Diese Methoden erforderten von der Anwendung die Verwendung bestimmter Sicherheitsprotokolle, die kompliziert sind und schwierig zu implementieren sein können. Daher ist es einfacher, sich aus Sicherheitsgründen nur auf HTTPS zu verlassen, damit sich Anwendungsentwickler keine Sorgen machen müssen.

Die Antwort auf Ihre anderen Fragen hängt 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 wurde viel über das OAuth 2-Protokoll selbst diskutiert. Wie Sie sehen können, haben Facebook, Google und einige andere jeweils leicht unterschiedliche Versionen der implementierten Protokolle. Einige Leute bleiben also bei OAuth 1, weil es auf den verschiedenen Plattformen einheitlicher ist. Vor kurzem wurde das OAuth 2-Protokoll fertiggestellt, aber wir müssen noch sehen, wie es angenommen wird.

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

ein trostloser Artikel

und 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 Weise ist SSL nicht sicher, da der Server die Verbindung nicht überprüft und die allgemeinen Clientbibliotheken das Ignorieren von Fehlern erleichtern.

  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 das Ignorieren eines Fehlers zum Erfolg führt, werden Entwickler genau das tun. Der Server hat keine Möglichkeit, die Zertifikatsüberprüfung zu erzwingen, und selbst wenn dies möglich wäre, wird ein Angreifer dies sicherlich nicht tun.

• Sie können Ihre gesamte Sicherheit verlieren, was in OAuth 1.0 viel schwieriger ist:

  Das zweite häufige potenzielle Problem sind Tippfehler. Würden Sie es als richtiges Design betrachten, wenn ein Zeichen (das 's' in 'https') weggelassen wird, wodurch die gesamte Sicherheit des Tokens ungültig wird? Oder senden Sie die Anfrage (über eine gültige und verifizierte SSL / TLS-Verbindung) an das falsche Ziel (z. B. " http://gacebook.com "?). Denken Sie daran, dass die Verwendung von OAuth-Träger-Token über die Befehlszeile eindeutig ein Befürworter von Befürwortern von Anwendungsfall-Träger-Token war.

Die Sicherheit des OAuth 1.0-Protokolls ( RFC 5849 ) basiert 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 vertraulich zu behandeln, als öffentlicher Client bezeichnet. Siehe 2.1. Client-Typen 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, es jedoch keinen praktischen Unterschied in der Sicherheitsstufe zwischen OAuth 1.0-Clients und vertraulichen OAuth 2.0-Clients gibt. 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, im Vergleich zu der Einfachheit , dass ein OAuth 2.0 - Client eine Verbindung zu einem Server über TLS und einfach präsentiert client_idund client_secretkann nicht gesagt werden , dass die umständliche Berechnung besser ist in Bezug auf die Sicherheit.

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

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

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 gemeinsam genutzter Schlüssel für HMAC-SHA1 ( RFC 5849, 3.4.2 ) oder ein privater Schlüssel für RSA-SHA1 ( RFC 5849, 3.4.3 ) ist. 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 OAuth 1.0-Sicherheit benötigt wird, ist nur die Bedingung, dass ein geheimer Schlüssel vertraulich behandelt werden kann. Dies mag extrem klingen, aber die Signaturberechnung fügt keine Sicherheitsverbesserung hinzu, wenn die Bedingung bereits erfüllt ist.

Ebenso verlassen sich vertrauliche OAuth 2.0- Clients auf dieselbe Bedingung. Wenn die Bedingung bereits erfüllt ist, gibt es ein Problem beim Erstellen einer sicheren Verbindung mit TLS und beim Senden client_idund Senden client_secretan einen Autorisierungsserver über die gesicherte Verbindung? Gibt es einen großen Unterschied in der Sicherheitsstufe zwischen vertraulichen OAuth 1.0- und OAuth 2.0-Clients, wenn beide auf derselben Bedingung beruhen?

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

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. Die Endpunkte der geschützten Ressourcen müssen Zugriff auf die Clientanmeldeinformationen haben, um die Anforderung zu validieren.

Hier wird der Unterschied zwischen OAuth 1.0 und 2.0 beschrieben und wie beide funktionieren.

OAuth 2 ist anscheinend 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 verknüpft werden. Ich gab meine Rolle als Hauptautor und Herausgeber auf, zog meinen Namen aus der Spezifikation zurück und verließ die Arbeitsgruppe. Es war nicht einfach, meinen Namen aus einem Dokument zu entfernen, an dem ich drei Jahre lang sorgfältig gearbeitet habe, und über zwei Dutzend Entwürfe waren nicht einfach. Die Entscheidung, mich von einer Anstrengung zu lösen, die ich seit über fünf Jahren führe, 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 möchte. ... 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, wird OAuth 2.0 von einem Entwickler mit tiefem Verständnis der Websicherheit wahrscheinlich zu einer sicheren Implementierung führen. In den Händen der meisten Entwickler wird 2.0 - wie die Erfahrung der letzten zwei Jahre gezeigt hat - wahrscheinlich zu unsicheren Implementierungen führen.

Wenn Sie eine ausführliche 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 Flussunterschiede benötigen, kann dies hilfreich sein:

OAuth 1.0 Flow

1. Die Clientanwendung wird beim Anbieter registriert, z. B. bei Twitter.
2. Twitter bietet dem Kunden ein für diese Anwendung einzigartiges „Verbrauchergeheimnis“.
3. Die Client-App signiert alle OAuth-Anfragen bei Twitter mit ihrem einzigartigen „Verbrauchergeheimnis“.
4. Wenn eine der OAuth-Anforderungen fehlerhaft ist, Daten fehlen oder nicht ordnungsgemäß signiert sind, wird die Anforderung abgelehnt.

OAuth 2.0 Flow

1. Die Clientanwendung wird beim Anbieter registriert, z. B. bei Twitter.
2. Twitter bietet dem Kunden ein für diese Anwendung einzigartiges „Kundengeheimnis“.
3. Die Client-Anwendung enthält "Client Secret" mit jeder Anforderung, die üblicherweise als http-Header bezeichnet wird.
4. Wenn eine der OAuth-Anforderungen fehlerhaft ist, Daten fehlen oder das falsche Geheimnis enthalten, wird die Anforderung abgelehnt.

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

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 benötigt werden.
2. Für die eigentlichen API-Aufrufe nach der Generierung des Tokens sind keine Signaturen erforderlich. Auch hier wird SSL dringend empfohlen.
3. Nach der Generierung des Tokens erforderte OAuth 1.0, dass der Client bei jedem API-Aufruf zwei Sicherheitstoken sendet und beide zum Generieren der Signatur verwendet. OAuth 2.0 verfügt nur über ein Sicherheitstoken, und es ist keine Signatur erforderlich.
4. Es ist klar festgelegt, welche Teile des Protokolls vom "Ressourcenbesitzer" implementiert werden, welcher der eigentliche Server ist, der die API implementiert, und welche Teile von einem separaten "Autorisierungsserver" implementiert werden können. Dadurch können Produkte wie Apigee vorhandene APIs mit OAuth 2.0 unterstützen.

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

Aus Sicherheitsgründen würde ich mich für OAuth 1 entscheiden. Siehe OAuth 2.0 und den Weg zur Hölle

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

Wenn Sie neu in diesem Bereich sind und sich als Sicherheitsexperte betrachten, verwenden Sie 2.0 nach sorgfältiger Prüfung der Funktionen. Wenn Sie kein Experte sind, verwenden Sie entweder 1.0 oder kopieren Sie die 2.0-Implementierung eines Anbieters, dem Sie vertrauen, um sie richtig zu machen (die API-Dokumente von Facebook sind ein guter Ausgangspunkt). 2.0 ist besser für große Unternehmen, aber wenn Sie einen größeren Vorgang ausführen, haben Sie wahrscheinlich einige Sicherheitsexperten vor Ort, die alles für Sie herausfinden. "