it-swarm.com.de

OAuth2 ROPC vs Basic Auth für öffentliche REST APIs?

Der spezielle Anwendungsfall, an dem ich hier interessiert bin, ist die Authentifizierung von REST Clients gegen öffentlich verfügbare Serverendpunkte (z. B. eine öffentliche REST API)).

Die einfachste Lösung ist hier Basic Auth . Aber ich höre oft, wie OAuth2 unter fast allen Umständen als überlegene Authentifizierungslösung angepriesen wird.

Die Sache ist, der nur OAuth2-Grant-Typ, der für einen REST Client, der sich gegen einen REST Server authentifiziert) möglich ist, ist - ROPC (Resource Owner Password Credentials) , da für Code Grants und implizite Grants eine Benutzeroberfläche/Webseite erforderlich ist (vom Auth Server gehostet) Damit sich der Benutzer bei der Client-App anmelden und diese manuell autorisieren kann.

ROPC funktioniert so, dass der Benutzername/das Kennwort des Ressourcenbesitzers und die Client-ID als Parameter für Abfragezeichenfolgen?!? Dies ist noch weniger sicher (IMHO) als Basic Auth, das mindestens Base-64 die Anmeldeinformationen codiert und sie in einem Header sendet, der mit TLS verschlüsselt werden kann!

Also frage ich: Ist OAuth2 ROPC wirklich im Kontext von public REST APIs) besser als Basic Auth? Was ist sicherer als OAuth2 ROPC?


Aktualisieren

Ich habe gerade diesen ausgezeichneten Artikel gelesen, der die nicht auf OAuth2 basierende REST Sicherheit für AWS) von Amazon erklärt. Es handelt sich im Wesentlichen um eine auf privaten Schlüsseln basierende Lösung, bei der Hashes von jedem REST Anfrage wird generiert und als Sidecars neben der normalen (unverschlüsselten) Anfrage gesendet. Nur der Client und der Server kennen den privaten Schlüssel, also wenn der Server die Anfrage empfängt (wieder mit der normalen) Anfrage + die Hash-Anfrage), der Server sucht nach dem privaten Schlüssel des Clients, wendet denselben Hash auf die normale Anfrage an und vergleicht dann die beiden Hashes.

Das klingt viel komplizierter, komplexer und sicherer als OAuth2s ROPC! Es sei denn, ich vermisse etwas major hier, OAuth2 ROPC sendet nur client_id, username und password als Abfragezeichenfolgenparameter ... völlig und absolut unsicher! Diese HMAC/Hash-basierte Lösung scheint viel beeindruckender und sicherer zu sein.

Die Sache ist, sogar der Autor dieses Artikels sagt weiter:

Sie werden auch langsam erkennen und akzeptieren, dass Sie irgendwann OAuth implementieren müssen ...

Ba-ba-bwhat?!?! Wenn OAuth2 weniger sicher ist als diese clevere HMAC/Hash-basierte Lösung , warum fühlt sich der Autor dieses Artikels OAuth muss irgendwann umarmt werden. Ich bin so verwirrt.

22
smeeb

Die Antwort auf Ihre Frage kann auf Code-, Protokollebene oder Architekturebene erfolgen. Ich werde versuchen, hier die meisten Probleme auf Protokollebene zusammenzufassen, da dies normalerweise für die Vor- und Nachteile der Analyse von entscheidender Bedeutung ist. Beachten Sie, dass OAuth2 viel mehr ist als Resource Owner Password Credentials , das laut Spezifikation aus "Legacy- oder Migrationsgründen" existiert und als "höheres Risiko als andere" gilt Grant-Typen "und die Spezifikation besagt ausdrücklich, dass die Clients und Autorisierungsserver" die Verwendung dieses Grant-Typs minimieren und nach Möglichkeit andere Grant-Typen verwenden sollten ".

Es gibt immer noch viele Vorteile der Verwendung von ROPC gegenüber der Basisauthentifizierung. Bevor wir jedoch darauf eingehen, sollten wir den grundlegenden Protokollunterschied zwischen OAuth2 und Basisauthentifizierung verstehen. Bitte nehmen Sie Kontakt mit mir auf, wenn ich diese erkläre, und kommen Sie später zu ROPC.

Benutzerauthentifizierungsabläufe

In der OAuth2-Spezifikation sind vier Rollen definiert. Mit Beispielen sind sie:

  1. Ressourceneigentümer: Der Benutzer, der Zugriff auf eine Ressource hat, z. In Ihrem Fall haben verschiedene Benutzer möglicherweise unterschiedliche Zugriffsebenen auf die REST API;
  2. Der Client: Normalerweise die Anwendung, die der Benutzer verwendet, und benötigt Zugriff auf die Ressource, um dem Benutzer Dienste bereitzustellen.
  3. Ressourcenserver: die REST API in Ihrem Fall; und
  4. Autorisierungsserver: Der Server, auf dem die Anmeldeinformationen des Benutzers angezeigt werden und der den Benutzer authentifiziert.

Wenn eine Clientanwendung ausgeführt wird, wird ihr basierend auf dem Benutzer Zugriff auf die Ressourcen gewährt. Wenn ein Benutzer über Administratorrechte verfügt, sind die Ressourcen und Vorgänge, die dem Benutzer in der API REST API) zur Verfügung stehen, möglicherweise weit mehr als ein Benutzer ohne Administratorrechte.

OAuth2 bietet auch die Möglichkeit, einen einzelnen Autorisierungsserver mit mehreren Clients und für mehrere Ressourcen zu verwenden. Beispielsweise kann ein Ressourcenserver die Authentifizierung des Benutzers bei Facebook akzeptieren (der in einem solchen Fall als Autorisierungsserver fungieren kann). Wenn der Benutzer eine Anwendung (d. H. Den Client) ausführt, sendet er den Benutzer an Facebook. Der Benutzer gibt seine Anmeldeinformationen in Facebook ein und der Client erhält ein "Token" zurück, das er dem Ressourcenserver präsentieren kann. Der Ressourcenserver überprüft das Token und akzeptiert es, nachdem überprüft wurde, ob Facebook es tatsächlich ausgestellt hat, und ermöglicht dem Benutzer den Zugriff auf die Ressource. In diesem Fall sieht der Client niemals die Anmeldeinformationen des Benutzers (d. H. Seine Facebook-Anmeldeinformationen).

Angenommen, Sie verwalten die Identität Ihres Benutzers (und verfügen über einen Autorisierungsserver) anstelle von Facebook, wodurch Ihrem Kunden bereits Token gewährt werden. Angenommen, Sie haben auch einen Partner und möchten dessen Anwendung (dh Client) den Zugriff auf Ihre REST API) ermöglichen. Mit der Basisauthentifizierung (oder sogar ROPC) gibt der Benutzer Anmeldeinformationen an Der Client, der es an den Autorisierungsserver sendet. Der Autorisierungsserver stellt dann ein Token bereit, mit dem der Client auf die Ressourcen zugreifen kann. Leider bedeutet dies, dass die Anmeldeinformationen des Benutzers jetzt auch für diesen Client sichtbar sind. Dies ist jedoch nicht der Fall Die Anwendung eines Partners (der möglicherweise außerhalb Ihres Unternehmens liegt) möchte sogar das Kennwort eines Benutzers kennen. Dies ist jetzt ein Sicherheitsproblem. Um dieses Ziel zu erreichen, möchten Sie einen anderen Ablauf (z. B. die Erteilung des Autorisierungscodes) verwenden, in dem Der Benutzer stellt dem Autorisierungsserver direkt Anmeldeinformationen zur Verfügung.

Daher würde man mit OAuth2 in solchen Fällen idealerweise kein ROPC verwenden, sondern ein anderes, wie z. B. den Autorisierungscode-Fluss. Dies schützt jede Anwendung vor der Kenntnis der Anmeldeinformationen des Benutzers, die nur dem Autorisierungsserver angezeigt werden. Somit werden die Anmeldeinformationen eines Benutzers nicht durchgesickert. Die gleichen Probleme treten bei der Basisauthentifizierung auf, aber im nächsten Abschnitt werde ich erläutern, wie ROPC immer noch besser ist, da die Anmeldeinformationen des Benutzers vom Client in ROPC nicht gespeichert werden müssen, damit die Clients dauerhaft darauf zugreifen können.

Beachten Sie, dass der Autorisierungsserver den Benutzer beim Aufrufen des Autorisierungsservers auch auffordern kann, zu bestätigen, dass er dem Client den Zugriff auf die Ressourcen in seinem Namen ermöglichen möchte oder nicht. Aus diesem Grund wird es als Autorisierungsserver bezeichnet, da der Prozess der Autorisierung eines Clients für den Zugriff auf Ressourcen mit dem Prozess verbunden ist. Wenn der Benutzer den Client nicht autorisiert, erhält er keinen Zugriff auf die Ressourcen. Wenn der Benutzer selbst keinen Zugriff auf die Ressourcen hat, kann der Autorisierungsserver den Zugriff weiterhin verweigern und kein Token ausstellen.

Bei der Basisauthentifizierung werden sogar der Autorisierungsserver und der Ressourcenserver zu einer einzigen Entität zusammengefasst. Daher möchte der Ressourcenserver den Benutzer autorisieren und fragt den Client nach den Anmeldeinformationen. Der Client stellt die Anmeldeinformationen bereit, die vom Ressourcenserver zur Authentifizierung des Benutzers verwendet werden. Dies bedeutet, dass mehrere Ressourcenserver im Wesentlichen Anmeldeinformationen vom Benutzer benötigen.

Token-Ausgabe

Die Clients erhalten Token vom Autorisierungsserver, behalten sie bei und verwenden diese, um auf die Ressourcen zuzugreifen (weitere Details zu den Token selbst weiter unten). Die Clients kennen das Kennwort des Benutzers (in anderen Flows als ROPC) nie und müssen es nicht speichern. In ROPC müssen die Clients das Kennwort des Benutzers zwar kennen, müssen es jedoch nicht speichern, da sie diese Token für den Zugriff auf Ressourcen verwenden. Wenn ein Client bei der Basisauthentifizierung nicht möchte, dass der Benutzer in jeder Sitzung Anmeldeinformationen bereitstellt, muss er das Kennwort des Benutzers speichern, damit er es beim nächsten Mal bereitstellen kann. Dies ist ein Hauptnachteil bei der Verwendung der Basisauthentifizierung, es sei denn, der Client ist nur eine Webanwendung. In diesem Fall können Cookies einige dieser Probleme beheben. Bei nativen Anwendungen ist dies normalerweise keine Option.

Es gibt einen weiteren Aspekt von OAuth2, der darin besteht, wie Token ausgegeben werden und wie sie funktionieren. Wenn ein Benutzer dem Autorisierungsserver (auch in ROPC) Anmeldeinformationen bereitstellt, kann der Autorisierungsserver einen oder mehrere der beiden Arten von Token vergeben: 1) Zugriffstoken und 2) Aktualisierungstoken.

Zugriffstoken werden an den Ressourcenserver gesendet, der nach der Validierung Zugriff auf die Ressourcen gewährt, und normalerweise haben sie eine kurze Lebensdauer, z. 1 Stunde. Aktualisierungstoken werden vom Client an den Autorisierungsserver gesendet, um nach Ablauf ein weiteres Zugriffstoken zu erhalten, und haben normalerweise eine lange Lebensdauer (z. B. einige Tage bis Monate oder sogar Jahre).

Wenn der Client das Zugriffstoken für den Ressourcenserver bereitstellt, überprüft er das Token und prüft nach der Validierung das Token, um festzustellen, ob der Zugriff zugelassen werden soll oder nicht. Solange das Zugriffstoken gültig ist, kann der Client es weiterhin verwenden. Angenommen, der Benutzer schließt die Anwendung und startet sie am nächsten Tag, und das Zugriffstoken ist abgelaufen. Jetzt ruft der Client den Autorisierungsserver an und zeigt das Aktualisierungstoken an, sofern es nicht abgelaufen ist. Da der Autorisierungsserver das Token bereits ausgestellt hat, überprüft er es und kann feststellen, dass der Benutzer die Anmeldeinformationen nicht erneut bereitstellen muss, und gibt dem Client somit ein weiteres Zugriffstoken. Der Client hat jetzt wieder Zugriff auf den Ressourcenserver. Auf diese Weise fragen die Clientanwendungen für Facebook und Twitter in der Regel einmal nach Anmeldeinformationen und erfordern dann nicht, dass der Benutzer erneut Anmeldeinformationen bereitstellt. Diese Anwendungen müssen niemals die Anmeldeinformationen des Benutzers kennen und können dennoch jedes Mal auf Ressourcen zugreifen, wenn der Benutzer die Anwendung startet.

Jetzt kann der Benutzer in den Autorisierungsserver (z. B. in seinem Facebook-Benutzerprofil) das Kennwort ändern, ohne dass dies Auswirkungen auf Clientanwendungen hat. Sie werden alle weiterhin ordnungsgemäß funktionieren. Wenn der Benutzer ein Gerät verliert, auf dem er bereits eine Anwendung mit Aktualisierungstoken hatte, kann er den Autorisierungsserver (z. B. Facebook) anweisen, sich von den Anwendungen "abzumelden", die der Autorisierungsserver (dh Facebook) ausführen wird, indem er keine vorhandenen Anwendungen berücksichtigt Aktualisieren Sie Token und zwingen Sie den Benutzer, erneut Anmeldeinformationen anzugeben, wenn er versucht, über diese Anwendungen auf Ressourcen zuzugreifen.

JWT ist einfach das Token-Format, das normalerweise mit OAuth2 und OpenID Connect verwendet wird. Die Methoden zum Signieren und Validieren des Tokens sind auch mit Bibliotheken standardisiert, die für diese verfügbar sind, anstatt dass jeder Ressourcenserver eine weitere Lösung implementiert. Der Vorteil liegt somit in der Wiederverwendbarkeit von Code, der überprüft wurde und weiterhin unterstützt wird.

Auswirkungen auf die Sicherheit

Die Standardauthentifizierung ist schwächer, wenn eines der oben genannten Szenarien im Bild dargestellt ist. Es gibt auch ein umfangreiches Bedrohungsmodell für OAuth2 für Entwickler, die die darin enthaltenen Vorschläge verwenden können, um häufige Schwachstellen in ihren Implementierungen zu vermeiden. Wenn Sie das Bedrohungsmodell durchgehen, werden Sie feststellen, dass viele implementierungsbezogene Schwachstellen (wie Open Redirector und CSRF) ebenfalls darin behandelt werden. Ich habe diese in dieser Antwort nicht mit der Basisauthentifizierung verglichen.

Der letzte große Vorteil von OAuth2 besteht darin, dass das Protokoll standardisiert ist und von mehreren Autorisierungsservern, Clients und Ressourcenservern anerkannt wird. Entwicklern stehen zahlreiche Bibliotheken zur Verfügung, die verwaltet werden. Da bei Implementierungen Sicherheitsprobleme auftreten, werden die Bibliotheken aktualisiert und gleichzeitig Interoperabilität ermöglicht.

Schlussfolgerung

Wenn Sie eine neue Anwendung, IMO, schreiben, besteht der Idealfall darin, sowohl die Basisauthentifizierung als auch ROPC aufgrund der damit verbundenen Probleme zu vermeiden. Jede Anwendung hat jedoch unterschiedliche Anforderungen, Zeitpläne, Entwicklerkenntnisse usw., sodass die Entscheidung von Fall zu Fall fällt. Aber selbst wenn Sie nicht mehr als die Basisauthentifizierung benötigen, können Sie sich durch Auswahl in eine Architektur einschließen, die möglicherweise nicht einfach zu erweitern ist (z. B. wenn Sie in Zukunft mehrere Server haben, möchten Sie dies nicht unbedingt Der Benutzer stellt jedem von ihnen Anmeldeinformationen zur Verfügung, anstatt sie nur einmal dem Autorisierungsserver zur Verfügung zu stellen, der Token usw. aushändigen kann.)

Beachten Sie, dass ich Ihren Kommentar dazu, wie die Anmeldeinformationen über das Kabel gesendet werden, nicht angesprochen habe, da diese mit TLS oder einem ähnlichen Protokoll oder einem Besitznachweis usw. gesichert werden können. Wie bereits erwähnt, ist die Basis-64-Codierung keine Sicherheit, bitte nicht sich davon täuschen lassen. Die oben genannten Unterschiede liegen normalerweise auf architektonischer Ebene, und daher habe ich mich darauf konzentriert, da Architektur nach ihrer Implementierung am schwierigsten zu ändern ist.

Azure Active Directory B2C Basic , ein Dienst, an dem ich arbeite und der kürzlich für die öffentliche Vorschau freigegeben wurde, ermöglicht es Drittanbieteranwendungen, AAD als Autorisierungsserver mit Interoperabilität mit sozialen IDPs (wie Facebook, Google, usw.). Außerdem können Benutzer ihre eigenen Konten erstellen, anstatt soziale IDPs zu verwenden. Diese können später für Authentifizierungszwecke verwendet werden. Es gibt auch einige andere Dienste wie diesen (z. B. einen anderen, den ich kenne, ist auth ), die von Entwicklern verwendet werden können, um die Authentifizierung und Benutzerverwaltung für ihre Anwendungen und Ressourcen vollständig auszulagern. Die gleichen Protokolleigenschaften, die ich oben erwähnt habe, werden von Entwicklern verwendet, um den Autorisierungsserver (AAD), eine Ressource (z. B. ihre REST APIs), den Client (z. B. ihre mobilen Anwendungen) und Benutzer zu entkoppeln. Ich hoffe diese Erklärung hilft etwas.

25
Omer Iqbal

Die Standardauthentifizierung ist kein guter Weg, um Ihre REST API) zu sichern. Ich habe die Gründe erklärt, warum in dieser Antwort .

Wenn Sie eine REST API) erstellen, implementieren Sie Ressourcenserver in OAuth2-Begriffen. Ihre API muss lediglich überprüfen, ob das Token zusammen mit der Anforderung in übergeben wurde Der Autorisierungs-HTTP-Header ist gültig und stammt von einem vertrauenswürdigen Aussteller. Unter dieser Link finden Sie Schritte zum Implementieren der Validierung, wenn keine Bibliothek verfügbar ist.

Wie Ihr Client erwirbt das Token vom Autorisierungsserver, hängt davon ab, was Art des Clients es ist. Denken Sie daran, dass Sie den Clienttyp angeben müssen, den Sie verwenden möchten, wenn Sie den Client beim Autorisierungsserver registrieren.

Wenn eine Webanwendung mit Ihrem Server kommuniziert, kann sie Autorisierungscode-Erteilung verwenden. Wenn es sich um einen nicht vertrauenswürdigen Client wie eine mobile Anwendung oder eine JavaScript-App handelt, sollte implizite Gewährung verwendet werden.

Für Backend-Services, die nicht mit einem Ressourcenbesitzer interagieren können, können Sie Client-Anmeldeinformationen gewähren verwenden. Für Befehlszeilentools können Sie entweder Client-Anmeldeinformationen oder Kennwort für Ressourcenbesitzer verwenden.

Es hängt alles davon ab, welche Art von Client Sie verwenden.

Schließlich erfolgt die Validierung eines JWT-Tokens auf dem Ressourcenserver, ohne dass mit dem Autorisierungsserver gesprochen werden muss. Dies führt zu einer besser skalierbaren Architektur als Lösungen, die private Daten für jeden Client nachschlagen müssen.

3
MvdD

Ich glaube, Sie sind über die Verschlüsselung von GET-Variablen in einer URL falsch informiert

Die einzigen Personen, die die GET-Variablen in einer Anforderung anzeigen können, sind der Originalcomputer und der empfangende Server ( Link ).

Nur die DNS-Suche basierend auf der Domäne, an die die HTTPS-Anforderung gesendet wird, wird nicht verschlüsselt. Alles andere, die Ports, die GET-Variablen und die Ressourcen-ID, sind verschlüsselt.

Die einzige Einschränkung besteht darin, dass der empfangende Server möglicherweise den vollständigen Anforderungspfad abmeldet, Sie jedoch die Kontrolle darüber haben, damit Sie diese Daten nach Belieben schützen können.

3
Patrick

Es ist entweder sicher oder nicht sicher. Nicht mehr und nicht weniger. Mit base64 wird Basic Auth (oder etwas anderes) nicht sicherer.

Es ist nichts Falsches daran, etwas unverschlüsseltes zu senden, wenn es eine verschlüsselte Pipe wie Https verwendet.

OAuth hat mehr Funktionen, verwenden Sie es, wenn Sie es brauchen. Für alles andere, z. Banking, mit grundlegenden Challenge-Response ist in Ordnung und sicher.

1
imel96

Ich denke, Sie müssen zuerst die Terminologien verstehen. Sie vergleichen Autorisierung und Digitale Signatur

OAuth ist ein offener Standard für die Autorisierung , bei der Amazon (gemäß dem Artikel und den in Ihrer Frage angegebenen Details) eine gültige digitale Signatur erstellt gibt einem Empfänger (hier Amazon) Grund zu der Annahme, dass die Nachricht von einem bekannten Absender erstellt wurde, dass der Absender nicht leugnen kann, die Nachricht gesendet zu haben ( Authentifizierung und Nicht-Zurückweisung)

Welcher Autorisierungsmechanismus verwendet werden soll, hängt mehr oder weniger von Ihrem Anwendungsfall ab.

Unten finden Sie Informationen zu StackOverflow hier :

Grundlegende Authentifizierung, die ein sehr einfaches Hashing erfordert, um den einzelnen erforderlichen Header zu berechnen - OAuth ist ohne Zweifel eine teurere Authentifizierung. Wichtig ist, dass die beiden Authentifizierungsmechanismen völlig unterschiedlich sind Grundlegende Authentifizierung dient zur Authentifizierung eines Clients bei einer primären Anwendung. OAuth dient zum Autorisieren eines Drittanbieters für den Zugriff auf Clientdaten aus einer primären Anwendung. Beide haben ihren Platz und sollten eine über der anderen auswählen durch den besonderen Anwendungsfall der Implementierung gesteuert werden.

Und hier ist noch ein interessanter Artikel Vergleich der beiden.

Die Standardauthentifizierung über SSL ist unter dem Gesichtspunkt der vereinfachenden Sicherheit tatsächlich ziemlich verantwortlich. Wenn wir mit Benutzernamen und Passwörtern zu kämpfen haben, ist Basic Auth eine weit verbreitete Lösung, da es so einfach zu implementieren ist. Die Übertragung von Anmeldeinformationen erfolgt über SSL, und die Verwendung des Headers "Authorization" ist in HTTP-Clients und -Systemen allgegenwärtig.

0
Guanxi