it-swarm.com.de

OAuth2 und Authentifizierung

Ich sehe viel Verwirrung über OAuth2 und Authentifizierung, deshalb habe ich diese Frage in der Hoffnung erstellt, etwas von der Verwirrung zu beseitigen. Sprechen wir also über die folgenden Punkte:

  1. Was ist der Unterschied zwischen Authentifizierung und Autorisierung?
  2. Was soll OAuth2 tun?
  3. Warum ist der implizite OAuth2-Fluss für die Authentifizierung unsicher und für die Autorisierung dennoch sicher? (Tipp: Zugriffstoken sind nicht an einen bestimmten Client gebunden.)
  4. Was ist der Unterschied zwischen dem impliziten OAuth2-Fluss und dem Fluss des Oauth2-Authentifizierungscodes und wann welcher zu verwenden ist?
  5. Funktioniert der OAuth2-Authentifizierungscode für die Authentifizierung?
  6. Sollten Sie OpenID anstelle von OAuth2 zur Authentifizierung verwenden?
  7. Warum sagt Google, dass das "OAuth2" -Framework sowohl für die Authentifizierung als auch für die Autorisierung verwendet werden kann?.

Google APIs verwenden das Protokoll OAuth 2.0) zur Authentifizierung und Autorisierung.

https://developers.google.com/identity/protocols/OAuth2

OAuth2-Spezifikation: https://tools.ietf.org/html/rfc6749

18
Gudradain
1.What is the difference between authentication and authorization?

Authentifizierung ist der Prozess, bei dem ein Server prüft, ob ein Benutzer tatsächlich der Benutzer ist, für den er sich ausgibt. Dies erfolgt normalerweise, wenn der Benutzer den Benutzernamen und ein Kennwort angibt, während der Server diese Anmeldeinformationen (Benutzername, Kennwort) mit denen vergleicht, die in seiner Datenbank gespeichert sind, als der erste Benutzer sein Konto erstellt hat. Autorisierung ist, wenn eine Entität einer anderen Entität die Berechtigung zum Ausführen einer Aktion erteilt. In diesem Fall möchte eine Site beispielsweise auf Daten eines Benutzers zugreifen, die auf einer anderen Website gespeichert sind und deren Eigentümer sie sind.

2.What is OAuth2 meant to do?

Offiziell ermöglicht OAuth2 einem Benutzer, einer Client-Website C den Zugriff auf seine Daten von einer Ressourcenserver-Website RS nach der Authentifizierung über eine Authentifizierungsserver-Website AS zu ermöglichen. Dies scheint recht komplex zu sein. Zur Vereinfachung ist ein häufiges Beispiel, wenn sich ein Benutzer mit seinem Facebook-Konto auf einer Website anmeldet. In diesem Fall sind die Client-Website und die Ressourcenserver-Website identisch (C = RS = die besuchte Website) und der Authentifizierungsserver ist Facebook (AS = Facebook). Beachten Sie, dass dies erstellt wurde, damit C, RS das Kennwort des Benutzers nicht lernen und ihn/sie authentifizieren können. (OAuth2 flow

3.Why is OAuth2 implicit flow insecure for authentication while still secure for authorization?

Die Besonderheit des impliziten Flusses ist die Tatsache, dass das Zugriffstoken an den Benutzeragenten übergeben wird, um es an die Anwendung weiterzuleiten. Es basiert also ausschließlich auf dem Umleitungs-URI. Daher authentifiziert dieser Datenfluss die Identität der Anwendung nicht, da keine geheime Vertraulichkeit des Clients besteht (Zugriffstoken für Benutzer und Anwendungen, die auf Mobilgeräten ausgeführt werden).

4.What is the difference between OAuth2 implicit flow and Oauth2 authentication code flow and when to use which?

Wie zuvor beschrieben, wird das Zugriffstoken im impliziten Ablauf vom Benutzeragenten an die Anwendung weitergeleitet. Andererseits erhält der Client-Webserver im Autorisierungscode-Fluss zuerst einen Autorisierungscode (nachdem der Ressourcenbesitzer/Benutzer Zugriff gewährt hat) und ruft dann die API-Übergabe (clientID, secretID) mit dem Autorisierungscode auf, um den zu erhalten Zugangstoken. Dies geschieht, damit bei HTTP-Verbindungen (keine SSL-Verschlüsselung) das Zugriffstoken für Man-in-the-Middle (Router, Proxys usw.) nicht zugänglich ist. Der erste ist also für mobile Anwendungen geeignet, während der zweite für serverseitige Anwendungen geeignet ist.

5.Does OAuth2 authentication code flow work for authentication?

Ja, der Autorisierungscode-Fluss authentifiziert den Benutzer auch über den Authentifizierungsserver.

6.Should you use OpenID instead of OAuth2 for authentication?

Ja.

OpenID wird zur Authentifizierung verwendet. Ein Beispiel ist, wenn Benutzer sich mit einem einzigen Satz von Anmeldeinformationen auf mehreren Websites anmelden können (Signle-Sign-On).

OAuth wird wie zuvor beschrieben für die Autorisierung verwendet. Beachten Sie, dass OAuth) leicht angepasst werden kann (wie im vorherigen Beispiel, wobei C = RS), um eine (Pseudo-) Authentifizierung über eine Autorisierung durchzuführen. Wenn wir jedoch nur eine Authentifizierung wünschen, müssen wir dies tun kann OpenID verwenden.

7.Why is google saying that their "OAuth2" framework can be used for both authentication and authorization.

Ich denke, die wahren Gründe für diese Entwurfsentscheidung können nur von den entsprechenden Google-Ingenieuren angegeben werden, aber ich könnte davon ausgehen, dass sie anstelle von OpenID und OAuth ein einziges Protokoll für beide Verwendungen verwenden, um die Dinge zu vereinfachen. Beachten Sie jedoch, dass die Authentifizierung über OAuth durch Authentifizierung einer Person anhand der Daten erfolgt, über die sie verfügt). Ein langweiliges Beispiel wäre, wenn ich versuche, das Gebäude meines Jobs zu betreten Ich werde nicht nach meinen Anmeldeinformationen gefragt, da sich meine Mitarbeiterkarte offensichtlich in meinem Nacken befindet. Auf diese Weise erfolgt die Authentifizierung über OAuth, ganz vereinfacht. Sie können also sehen, dass dies mehrere Annahmen treffen kann, die nicht immer unter allen gelten Dies ist der Grund, warum generell empfohlen wird, OAuth nur zur Autorisierung und Verwendung von OpenID zu verwenden, falls Sie auch die Authentifizierung implementieren müssen.

Ein netter Link, der die verschiedenen Flüsse von OAuth für Referenz beschreibt

15
Dimos

@RaptisDimos gab eine gute Antwort, aber ich denke, ich werde für Punkt 3 ausgeben.

  1. Warum ist der implizite OAuth2-Fluss für die Authentifizierung unsicher und für die Autorisierung dennoch sicher?

Das Problem mit dem impliziten Ablauf beim Versuch, ihn für die Authentifizierung zu verwenden, besteht darin, dass der Client direkt ein Zugriffstoken empfängt und das Zugriffstoken nicht an einen bestimmten Client gebunden ist. Dies bedeutet, dass der Client nicht weiß, ob dieses Token für ihn oder eine andere Anwendung bestimmt war.

Dieses Token wird dann verwendet, um auf die Eigentümerdaten zuzugreifen. Wenn Sie den Eigentümer "authentifizieren" möchten, ziehen Sie normalerweise seine E-Mail aus seinen Daten und authentifizieren ihn in Ihrer Anwendung (Client). Aber Sie wissen nicht, wer dieses Zugriffstoken an Ihren Client weitergegeben hat. War es der echte Eigentümer oder ein Angreifer, der einen anderen Dienst gehostet hat?

Beispiel eines Angriffs

  • Client_Good: Ein guter Client, der die Google-API verwendet, um seinen Benutzer mithilfe des impliziten Ablaufs zu authentifizieren
  • Client_Bad: Ein böswilliger Client, der die Google-API verwendet und Client_Good angreift

Client_Bad kann ein beliebiger Dienst sein. Zum Beispiel eine Webanwendung, mit der Sie Bilder in Ihr Google-Laufwerk hochladen können. Um diese Aufgabe zu erfüllen, benötigt Client_Bad ein Zugriffstoken von Google. Sie werden also gebeten, ihm einen zur Verfügung zu stellen. Anschließend können Sie den Dienst zum Hochladen Ihres Bilds verwenden.

Was Sie nicht wussten, ist, dass das Zugriffstoken, das Sie Client_Bad gerade zum Hochladen von Bildern gegeben haben, auch ein gültiges Zugriffstoken ist, das mit Client_Good verwendet werden kann, um sich zu authentifizieren. Jetzt kann sich der Eigentümer von Client_Bad in Client_Good als Sie ausgeben. Wenn Client_Good ein kritischer Dienst ist, liegt möglicherweise ein ernstes Problem vor.

Warum ist es dann für die Autorisierung sicher?

Es ist sicher, denn wenn Sie Client_Bad die Berechtigung zum Hochladen von Bildern in Ihrem Namen erteilen, spielt es keine Rolle, ob er dies direkt tut oder von einem anderen Dienst übergeben wird, um dies zu tun.

Zum Beispiel könnte es einen dritten Client geben, Client_Picture, der ebenfalls nur Bilder auf Ihr Google-Laufwerk hochlädt. Wenn Sie Client_Bad bitten, Ihre Daten hochzuladen, könnte Client_Bad diese Aufgabe an Client_Picture delegieren, und es wäre Ihnen egal, da das gleiche Ergebnis erzielt wird.

Nun, es gibt die Tatsache, dass jetzt eine Tonne von Drittanbietern Zugriff auf Ihre Daten haben könnte, aber Sie haben erneut zugestimmt, dass Client_Bad mit diesem Zugriffstoken alles tun kann, was es will, als Sie es gegeben haben. Es ist, als würden Sie den Schlüssel Ihres Autos an Ihren Nachbarn weitergeben. Sie haben jemand anderem das Recht gegeben, dieses Auto zu benutzen. Er könnte es dann für eine Weile an einen anderen Nachbarn ausleihen und es Ihnen dann zurückgeben. Die Sache ist, dass Sie es nicht wissen und dem "zugestimmt" haben, als Sie die Kontrolle gegeben haben.

Hinweis : Manchmal frage ich mich, ob niemand die Erklärung versteht oder ob ich etwas Falsches gesagt habe ... Wie auch immer, es wird im Abschnitt 10.16 der OAuth2-Spezifikation mit anderen Worten, wenn das hilft.

5
Gudradain