Share
In einer Welt, die von Social Media dominiert wird, ist es schwer, keine Clientanwendung zu finden, mit der Sie auf eingeschränkte Ressourcen auf einem anderen Server zugegriffen haben. Beispielsweise haben Sie möglicherweise eine webbasierte Anwendung (z. B. NY Times) für die gemeinsame Nutzung eines Servers verwendet interessanter Nachrichtenartikel auf Ihrer Facebook-Wand oder twittern darüber. Oder Sie haben Quoras iPhone-App verwendet, die auf Ihr Facebook- oder Google+ Profil zugreift und die Ergebnisse basierend auf Ihren Profildaten anpasst, z. B. den Vorschlag, basierend auf Ihrer Freundesliste andere Benutzer hinzuzufügen oder zu Quora einzuladen. Die Frage ist, wie diese Anwendungen auf Ihre Konten bei Facebook, Twitter oder Google+ zugreifen und wie sie auf Ihre vertraulichen Daten zugreifen können. Bevor sie dies tun können, müssen sie dem Ressourcenserver eine Form von Authentifizierungsnachweisen und Autorisierungsberechtigungen vorlegen.
OAuth wird oft als Valet Key für das Web beschrieben.
Nun wäre es wirklich so uncool Um Ihre Facebook- oder Google-Anmeldeinformationen mit einer Drittanbieter-Clientanwendung zu teilen, die nur über Ihre Freunde Bescheid wissen muss, gibt sie der App nicht nur unbegrenzten und unerwünschten Zugriff auf Ihr Konto, sondern weist auch die mit Kennwörtern verbundene Schwäche auf. An dieser Stelle kommt OAuth ins Spiel, da hier ein Zugriffsdelegierungs- / Berechtigungsrahmen skizziert wird, der verwendet werden kann, ohne dass Passwörter gemeinsam verwendet werden müssen. Aus diesem Grund wird OAuth oft als Valet Key für das Web beschrieben. Es kann als spezieller Schlüssel betrachtet werden, der den Zugriff auf begrenzte Funktionen und für einen begrenzten Zeitraum ermöglicht, ohne die vollständige Kontrolle zu verlieren, genau wie der Valet-Schlüssel für ein Auto es dem Parkwächter ermöglicht, das Auto für eine kurze Strecke zu fahren und zu blockieren Zugriff auf den Trunk und das Bordtelefon.
OAuth ist jedoch kein neues Konzept, sondern eine Standardisierung und kombinierte Weisheit vieler etablierter Protokolle. Erwähnenswert ist auch, dass OAuth nicht nur auf Social-Media-Anwendungen beschränkt ist, sondern eine standardisierte Möglichkeit bietet, Informationen sicher zwischen verschiedenen Arten von Anwendungen auszutauschen, die ihre APIs für andere Anwendungen verfügbar machen. OAuth 2.0 hat eine völlig neue Prosa und ist nicht abwärtskompatibel zu seiner Vorgängerspezifikation. Allerdings ist es gut, zuerst ein paar grundlegende OAuth2.0-Vokabeln zu behandeln, bevor in weitere Details eingegangen wird.
Der Hauptnachteil von OAuth 1.0 war die inhärente Komplexität, die zur Implementierung der Spezifikation erforderlich war.
Nichts wirklich! Twitter funktioniert mit OAuth 1.0 immer noch einwandfrei und unterstützt gerade einen kleinen Teil der 2.0-Spezifikation. OAuth 1.0 war eine durchdachte Spezifikation und ermöglichte den sicheren Austausch sicherer Informationen ohne den durch SSL verursachten Overhead. Der Grund, warum wir eine Überarbeitung brauchten, beruhte hauptsächlich auf der Komplexität bei der Implementierung der Spezifikation. Im Folgenden sind einige Bereiche aufgeführt, in denen OAuth 1.0 nicht beeindruckt:
Vor dem Initiieren des Protokolls muss sich der Client beim Autorisierungsserver registrieren, indem er seinen Client-Typ und seine Weiterleitungs-URL (an die der Autorisierungsserver weiterleiten soll, nachdem der Ressourcenbesitzer den Zugriff erteilt oder ablehnt) und alle anderen vom Server erforderlichen Informationen bereitstellt und wiederum wird eine Client-ID (client_id) und ein Client-Secret (client_secret) gegeben. Dieser Vorgang wird als Client-Registrierung bezeichnet. Nach der Registrierung kann der Client einen der folgenden Datenflüsse annehmen, um mit dem Server zu interagieren.
OAuth 2.0 bringt fünf neue Datenflüsse in die Tabelle ein und gibt Entwicklern die Flexibilität, einen von ihnen zu implementieren, je nach Art des involvierten Clients:
Eine ausführliche Diskussion der einzelnen Abläufe würde den Rahmen dieses Artikels sprengen. Ich würde eher empfehlen, die Spezifikation für ausführliche Flussinformationen zu lesen. Um ein Gefühl für das Geschehen zu bekommen, gehen wir näher auf einen der meist genutzten und unterstützten Flows ein: Den Webserver-Flow.
Da es sich um einen umleitungsbasierten Ablauf handelt, muss der Client in der Lage sein, mit dem Benutzeragenten des Ressourceninhabers (der in den meisten Fällen ein Webbrowser ist) zu interagieren, und ist daher normalerweise für eine Webanwendung geeignet. Das folgende Diagramm zeigt aus der Vogelperspektive, wie der Endbenutzer (oder der Besitzer der Ressource) die Clientanwendung (in diesem Fall die Anwendung auf dem Web-Server) verwendet, um sich beim Autorisierungsserver zu authentifizieren und zu autorisieren, um auf die geschützten Ressourcen zuzugreifen vom Ressourcenserver.
Der Client initiiert im Namen des Ressourceneigentümers den Fluss, indem er mit einem Parameter response_type zum Autorisierungsendpunkt umgeleitet wird Code, eine Client-ID, die während der Client-Registrierung abgerufen wird, eine Umleitungs-URL, einen angeforderten Bereich (optional) und einen lokalen Status (falls vorhanden). Um ein Gefühl dafür zu bekommen, wie es wirklich funktioniert, hier ein Screenshot, wie eine typische Anfrage / Antwort aussehen würde:
Dem Ressourceninhaber wird normalerweise eine Webschnittstelle angezeigt, über die er authentisieren und prüfen kann, welche Berechtigungen die Clientanwendung im Namen des Besitzers verwenden kann.
Unter der Annahme, dass der Ressourcenbesitzer dem Client Zugriff gewährt, leitet der Autorisierungsserver den Benutzeragenten mithilfe der zuvor angegebenen Umleitungs-URL zusammen mit dem Autorisierungscode, wie in der nachstehenden Antwort angegeben, zurück an den Client.
Der Kunde dann Beiträge an einen anderen Autorisierungsendpunkt senden und den im vorherigen Schritt erhaltenen Autorisierungscode zusammen mit der Umleitungs-URL, seiner Client-ID und seinem geheimen Code, die während der Clientregistrierung abgerufen wurden, und einem Parameter grant_type als festlegen Zugangscode.
Der Server überprüft dann den Autorisierungscode und stellt sicher, dass die Weiterleitungs-URL mit der im vorherigen Schritt identisch ist. Bei Erfolg antwortet der Server mit einem Zugriffstoken und optional einem Aktualisierungstoken.
Der Client kann nun die von der Implementierung bereitgestellten APIs verwenden und den Ressourcenserver nach einer eingeschränkten Ressource abfragen, indem er das Zugriffstoken im Authorization-Header der Anforderung weitergibt. Eine CURL-Beispielanforderung an das Blogger-API von Google, um ein Blog mit seiner Kennung zu erhalten, würde folgendermaßen aussehen:
$ curl https://www.googleapis.com/blogger/v3/blogs/5223788876950011016 -H 'Autorisierung: OAuth ya29.AHES6ZRTj1GNxAby81Es-p_YPWWNBAFRvBYVsYj2HZJfJHU'
Beachten Sie, dass wir das Access-Token als Autorisierungsheader der Anforderung hinzugefügt und das Token auch durch Einfügen in einfache Anführungszeichen ersetzt haben, da das Token Sonderzeichen enthalten kann. Beachten Sie, dass ein Fluchtweg vom Zugriffstoken nur bei Verwendung von curl erforderlich ist. Daraufhin wird folgende Anfrage gesendet:
Der Ressourcenserver überprüft dann die übergebenen Berechtigungsnachweise (Zugriffstoken) und antwortet bei Erfolg mit den angeforderten Informationen.
Diese Beispiele stammen von OAuth2.0 Playground und sind typisch für die Implementierung der Spezifikation durch Google. Unterschiede können beim Versuch auftreten, den gleichen Fluss mit anderen Anbietern (wie Facebook oder Salesforce) zu versuchen, und hier schleichen sich Interoperabilitätsprobleme ein, die wir später besprechen.
Zwar nicht von der Spezifikation vorgegeben, aber die Zugriffstoken sind in der Regel von kurzer Dauer und haben eine Verfallszeit. Wenn also ein Zugriffstoken abgelaufen ist, sendet der Client das Aktualisierungstoken zusammen mit seiner Client-ID und seinem geheimen Schlüssel sowie dem Parameter grant_type an den Autorisierungsserver refresh_token.
Der Autorisierungsserver antwortet dann mit dem neuen Wert für das Zugriffstoken.
Es gibt zwar einen Mechanismus, um das ausgegebene Aktualisierungstoken zu widerrufen, aber normalerweise bleibt das Aktualisierungstoken für immer erhalten und muss geschützt und als geheimer Wert behandelt werden.
Bei der Akzeptanzrate ist OAuth 2.0 definitiv eine Verbesserung gegenüber seinem armen Vorgänger. Instanzen von Entwicklergemeinschaften, die während der Implementierung der Signaturen von 1.0 ins Wanken geraten, sind nicht unbekannt. OAuth 2.0 bietet auch mehrere neue Grant-Typen, mit denen viele Anwendungsfälle wie native Anwendungen unterstützt werden können. Der USP dieser Spezifikation ist jedoch die Einfachheit gegenüber der Vorgängerversion.
Die Spezifikation hat ein paar lose Enden, da sie einige erforderliche Komponenten nicht richtig definiert oder sie den Implementierungen überlassen muss, um zu entscheiden, wie:
Lose Enden in der OAuth 2.0-Spezifikation führen wahrscheinlich zu einer Vielzahl von nicht interoperablen Implementierungen.
Die IETF benötigte 31 Entwurfsversionen und den Rücktritt des Hauptautors / Entwicklers Eran Hammer aus dem Gremium, um die Spezifikation endgültig zu veröffentlichen. Eran löste eine Kontroverse aus, indem er die Spezifikation anrief "ein schlechtes Protokoll und ein Todesfall um tausend Kürzungen". Ihm zufolge war die Verwendung von Inhaber-Token (Senden von Token über SSL ohne Signierung oder sonstige Überprüfung) über den Benutzer von Signaturen (oder MAC-Token), die in OAuth 1.0 zum Signieren der Anforderung verwendet werden, eine schlechte Bewegung und ein Ergebnis der Interessenverteilung zwischen Web- und Unternehmensgemeinschaften.
Die Spezifikation lässt sicherlich viele Erweiterungspunkte offen, was zu Implementierungen führt, die zusätzlich zu den bereits definierten Spezifikationen eigene Parameter einführen, und stellt sicher, dass Implementierungen von verschiedenen Anbietern nicht miteinander interagieren können. Aber mit der Beliebtheit und der Akzeptanzrate dieses Frameworks, bei dem jeder Big Player in der Stadt (Google, Twitter, Facebook, Salesforce, Foursquare, Github usw.) ihn so implementiert und optimiert, wie er will, ist OAuth keineswegs ein Misserfolg . In der Tat muss jede Webanwendung, die beabsichtigt, ihre APIs für andere Webanwendungen verfügbar zu machen, eine Form der Authentifizierung und Autorisierung unterstützen, und OAuth passt hier.
Accentsconagua