Kann jemand in 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, was mich daran zweifeln lässt, dass OAuth 2 einsatzbereit ist. Ist es das?
Eran Hammer-Lahav hat die meisten Unterschiede in seinem Artikel sehr gut erklärt Einführung von OAuth 2.0 . Zusammengefasst sind dies die wichtigsten Unterschiede:
Mehr OAuth Flows, um eine bessere Unterstützung für nicht browserbasierte Anwendungen zu ermöglichen. Dies ist ein Hauptkritikpunkt an OAuth von Client-Anwendungen, die nicht browserbasiert sind. Bei OAuth 1.0 mussten beispielsweise Desktop- oder Mobiltelefonanwendungen den Benutzer anweisen, seinen Browser zum gewünschten Dienst zu öffnen, sich bei dem Dienst zu authentifizieren und das Token vom Dienst zurück in die Anwendung zu kopieren. Die Hauptkritik richtet sich hier gegen die Benutzererfahrung. Mit OAuth 2.0 gibt es nun neue Möglichkeiten für eine Anwendung, die Autorisierung für einen Benutzer zu erhalten.
Für OAuth 2.0 ist es nicht mehr erforderlich, dass die Client-Anwendungen über Kryptographie verfügen. Dies erinnert an die alte Twitter-Auth-API, bei der die Anwendung keine HMAC-Hash-Tokens und Anforderungszeichenfolgen verwenden musste. Mit OAuth 2.0 kann die Anwendung eine Anfrage nur mit dem ausgegebenen Token über HTTPS stellen.
OAuth 2.0-Signaturen sind viel weniger kompliziert. Kein spezielles Parsen, Sortieren oder Kodieren mehr.
OAuth 2.0-Zugangs-Tokens sind "kurzlebig". Normalerweise können OAuth 1.0-Zugangs-Tokens ein Jahr oder länger gespeichert werden (Twitter lässt sie nie ablaufen). OAuth 2.0 hat den Begriff der Refresh-Tokens. Ich bin mir zwar nicht ganz sicher, was das ist, aber ich vermute, dass Ihre Zugriffs-Tokens kurzlebig sein können (d. h. sitzungsbasiert), während Ihre Refresh-Tokens "lebenslang" sein können. Sie würden ein Refresh-Token verwenden, um ein neues Zugriffstoken zu erhalten, anstatt den Benutzer zu bitten, Ihre Anwendung erneut zu autorisieren.
Schließlich soll OAuth 2.0 eine klare Rollentrennung zwischen dem Server, der für die Bearbeitung von OAuth-Anfragen zuständig ist, und dem Server, der die Benutzerautorisierung vornimmt, gewährleisten. Weitere Informationen dazu finden Sie in dem oben genannten Artikel.
Der Autor des Artikels schrieb letztes Jahr einen Folgeartikel mit dem Titel "OAuth 2.0 and the Road to Hell", der hier nachgelesen werden kann: web.archive.org/web/20120731155632/http://hueniverse.com/2012/ Ein wesentlicher Unterschied zwischen den beiden ist die Sicherheit - wie das Fehlen von Kryptographie in 2.0 bereits andeutet.
Die Sicherheit von OAuth 1.0 beruht auf der Annahme, dass ein geheimer Schlüssel, der in eine Client-Anwendung eingebettet ist, vertraulich behandelt werden kann, aber diese Annahme ist naiv. In OAuth 2.0 wird eine solche naive Client-Anwendung als vertraulicher Kunde . Es gibt keinen praktischen Unterschied im Sicherheitsniveau zwischen OAuth-1.0-Clients und vertraulichen OAuth-2.0-Clients. "OAuth 2.0 und der Weg zur Hölle" geht an diesem Punkt vorbei.
Ich sehe große Antworten hier oben, aber was ich vermisse, waren einige Diagramme und da ich mit Spring Framework arbeiten musste, stieß ich auf ihre Erklärung .
Ich finde die folgenden Diagramme sehr nützlich. Sie veranschaulichen den Unterschied in der Kommunikation zwischen Parteien mit OAuth2 und OAuth1.
Wenn Sie das Geheimnis meinen, das der Benutzer eingibt, wenn er zum Anbieter weitergeleitet wird (z. B. Facebook, Twitter, Google usw.), dann wäre dies Schritt 2 für OAuth 2 und Schritt 4 für OAuth 1 .
Warum gibt es in beiden Diagrammen einen Schritt des Dienstanbieters, der "User grants Authorization" heißt? Das scheint umgekehrt oder falsch zu sein. Ist nicht der "Benutzer" derjenige, der die Genehmigung beantragt?
Die bisherigen Erklärungen sind IMO alle zu detailliert und kompliziert. Einfach ausgedrückt: OAuth 2 delegiert die Sicherheit an das HTTPS-Protokoll. Bei OAuth 1 war dies nicht erforderlich, und folglich gab es alternative Methoden, um verschiedene Angriffe abzuwehren. Diese Methoden erforderten, dass sich die Anwendung auf bestimmte Sicherheitsprotokolle einlässt, die kompliziert sind und schwer zu implementieren sein können. Daher ist es einfacher, sich für die Sicherheit auf HTTPS zu verlassen, so dass sich die Anwendungsentwickler nicht darum kümmern müssen.
Was Ihre anderen Fragen betrifft, so hängt die Antwort davon ab. Einige Dienste wollen die Verwendung von HTTPS nicht vorschreiben, wurden vor OAuth 2 entwickelt oder haben andere Anforderungen, die sie an der Verwendung von OAuth 2 hindern könnten. Außerdem gab es viele Diskussionen über das OAuth 2-Protokoll selbst. Wie Sie sehen können, haben Facebook, Google und einige andere jeweils leicht abweichende Versionen des Protokolls implementiert. Daher bleiben einige Leute bei OAuth 1, weil es über die verschiedenen Plattformen hinweg einheitlicher ist. Vor kurzem wurde das OAuth 2-Protokoll fertiggestellt, aber wir müssen noch abwarten, wie es sich durchsetzt.
Sicherheit des OAuth 1.0-Protokolls ( RFC 5849 ) beruht auf der Annahme, dass ein in eine Client-Anwendung eingebetteter geheimer Schlüssel geheim gehalten werden kann. Diese Annahme ist jedoch naiv.
In OAuth 2.0 ( RFC 6749 ), wird eine solche naive Client-Anwendung als vertraulich Kunde. Andererseits wird eine Client-Anwendung in einer Umgebung, in der es schwierig ist, einen geheimen Schlüssel geheim zu halten, als öffentlich Kunde. Siehe 2.1. Client-Typen für Einzelheiten.
In diesem Sinne ist OAuth 1.0 eine Spezifikation nur für vertrauliche Clients.
" OAuth 2.0 und der Weg zur Hölle "Es heißt, dass OAuth 2.0 weniger sicher ist, aber es gibt keinen praktischen Unterschied im Sicherheitsniveau zwischen OAuth 1.0-Clients und vertraulichen OAuth 2.0-Clients. OAuth 1.0 erfordert die Berechnung der Signatur, aber das erhöht die Sicherheit nicht, wenn bereits sichergestellt ist, dass ein geheimer Schlüssel auf der Client-Seite vertraulich gehalten werden kann. Die Berechnung der Signatur ist nur eine umständliche Berechnung ohne praktische Sicherheitsverbesserung. Verglichen mit der Einfachheit, mit der sich ein OAuth 2.0-Client über TLS mit einem Server verbindet und einfach nur client_id y client_secret kann nicht behauptet werden, dass die umständliche Berechnung in Bezug auf die Sicherheit besser ist.
Außerdem wird in RFC 5849 (OAuth 1.0) nichts über offene Weiterleitungen während RFC 6749 (OAuth 2.0) dies tut. Das heißt, oauth_callback Parameter 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 zur Verdeutlichung meines Standpunkts
Die Sicherheit von OAuth 1.0 beruht auf der Berechnung von Signaturen. Eine Signatur wird unter Verwendung eines geheimen Schlüssels berechnet, wobei ein geheimer Schlüssel ein gemeinsamer Schlüssel für HMAC-SHA1 ist ( RFC 5849, 3.4.2 ) oder einen privaten Schlüssel für RSA-SHA1 ( RFC 5849, 3.4.3 ). Jeder, der den geheimen Schlüssel kennt, kann die Signatur errechnen. Wenn also der geheime Schlüssel kompromittiert ist, ist die Komplexität der Signaturberechnung bedeutungslos, wie komplex sie auch sein mag.
Das bedeutet, dass die Sicherheit von OAuth 1.0 nicht auf der Komplexität und Logik der Signaturberechnung beruht, sondern lediglich auf der Vertraulichkeit eines geheimen Schlüssels. Mit anderen Worten: Für die Sicherheit von OAuth 1.0 ist lediglich die Bedingung erforderlich, dass ein geheimer Schlüssel vertraulich gehalten werden kann. Das mag extrem klingen, aber die Berechnung von Unterschriften erhöht die Sicherheit nicht, wenn die Bedingung bereits erfüllt ist.
Ähnlich verhält es sich mit OAuth 2.0 vertraulich Die Kunden verlassen sich auf dieselbe Bedingung. Wenn die Bedingung bereits erfüllt ist, gibt es dann ein Problem beim Aufbau einer sicheren Verbindung mit TLS und dem Senden von client_id y client_secret zu einem Autorisierungsserver über die gesicherte Verbindung? Gibt es einen großen Unterschied im Sicherheitsniveau zwischen vertraulichen OAuth 1.0- und OAuth 2.0-Clients, wenn beide auf derselben Bedingung beruhen?
Ich kann keinen guten Grund finden, warum OAuth 1.0 OAuth 2.0 die Schuld geben sollte. Tatsache ist einfach, dass (1) OAuth 1.0 nur eine Spezifikation nur für vertrauliche Clients ist und (2) OAuth 2.0 das Protokoll für vertrauliche Clients vereinfacht und unterstützt hat öffentlich auch die Kunden. Unabhängig davon, ob es gut bekannt ist oder nicht, werden Smartphone-Anwendungen als öffentliche Clients eingestuft ( RFC 6749, 9 ), die von OAuth 2.0 profitieren.
Das Senden von Geheimnissen anstelle von Signaturen, sei es über HTTP, HTTPS usw., birgt immer ein implizites Sicherheitsrisiko aufgrund von MITM auf Protokollebene. Jetzt gibt es zwei Möglichkeiten, Geheimnisse zu finden, statt nur einer: Rooten Sie das Gerät, o Root-Zertifikate fälschen (ist schon vorgekommen, also nicht weit hergeholt). Wenn Ihr Sicherheitsmodell lautet: "Ach, lassen Sie den Transport das machen", dann wird es nicht WENIGER sicher sein als das Protokoll. Aber monolithische Sicherheitsmodelle == ein Einstiegspunkt für viele Dienste. Es ist "gut genug" für pragmatische Ingenieure, aber es wird nie "so sicher" sein wie ein alternatives dezentrales Modell.
Beachten Sie, dass es ernsthafte Sicherheitsargumente gegen die Verwendung von Oauth 2 gibt:
und eine eher technische Frage
Beachten Sie, dass diese von dem Hauptautor von Oauth 2 stammen.
Wichtige Punkte:
Oauth 2 bietet keine Sicherheit zusätzlich zu SSL, während Oauth 1 transportunabhängig ist.
SSL ist in gewisser Weise nicht sicher, da der Server die Verbindung nicht verifiziert und die gängigen Client-Bibliotheken es leicht machen, Fehler zu ignorieren.
Das Problem bei SSL/TLS ist, dass die Verbindung auch dann funktioniert, wenn das Zertifikat auf der Client-Seite nicht verifiziert werden kann. Jedes Mal, wenn das Ignorieren eines Fehlers zum Erfolg führt, werden die Entwickler genau das tun. Der Server hat keine Möglichkeit, eine Zertifikatsüberprüfung zu erzwingen, und selbst wenn er es könnte, würde ein Angreifer es sicher nicht tun.
können Sie Ihre gesamte Sicherheit aushebeln, was bei OAuth 1.0 sehr viel schwieriger zu bewerkstelligen ist:
Das zweite häufige potenzielle Problem sind Tippfehler. Würden Sie es für ein angemessenes Design halten, wenn das Auslassen eines Zeichens (das "s" in "https") die gesamte Sicherheit des Tokens zunichte macht? Oder wenn die Anfrage (über eine gültige und verifizierte SSL/TLS-Verbindung) an das falsche Ziel gesendet wird (z. B. ' http://gacebook.com '?). Denken Sie daran, dass die Möglichkeit, OAuth-Inhaber-Tokens von der Kommandozeile aus zu verwenden, eindeutig ein Anwendungsfall war, den die Befürworter von Inhaber-Tokens gefördert haben.
Das Argument "Tippfehler" ist nicht sehr stichhaltig - es ist gängige Praxis, von http auf https umzuleiten
@OlegMikheev Ja, aber es braucht nur eine http (no-s)-Anfrage, damit ein MITM Ihre Header ausspähen kann und Ihr Token nun von jemand anderem verwendet wird!
Wenn Sie mit Header Cookies meinen, dann sollten sie sicher . Abgesehen davon sehe ich nicht, wie ein Tippfehler des Benutzers (in der Browser-URL) Token freilegen kann, die nicht einmal in den Kopfzeilen enthalten sein sollten.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
0 Stimmen
Die Antwort finden Sie hier OAuth 2.0 - Überblick