Der spezielle Anwendungsfall, der mich interessiert, ist die Authentifizierung von REST-Clients anhand öffentlich verfügbarer Serverendpunkte (z. B. einer öffentlichen 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, dass der einzige OAuth2-Gewährungstyp, der für einen REST-Client, der sich gegenüber einem REST-Server authentifiziert, möglich ist, die Berechtigungsnachweise für das Kennwort des Ressourcenbesitzers ( Resource Owner Password Credentials, ROPC) sind , da für Codebewilligungen und implizite Bewilligungen eine (vom Authentifizierungsserver gehostete) Benutzeroberfläche / Webseite erforderlich ist Benutzer zum Anmelden und manuellen Autorisieren der Client-App.
Die Funktionsweise von ROPC besteht darin, den Benutzernamen / das Kennwort des Ressourcenbesitzers und die Client-ID als Abfragezeichenfolgenparameter zu senden ?!? Dies ist noch weniger sicher (IMHO) als Basic Auth, bei dem mindestens Base-64 die Anmeldeinformationen codiert und in einem Header sendet, der mit TLS verschlüsselt werden kann!
Ich frage also: Ist OAuth2 ROPC im Zusammenhang mit öffentlichen REST-APIs wirklich besser als Basic Auth? Was ist sicherer als OAuth2 ROPC?
Aktualisieren
Ich habe gerade diesen hervorragenden Artikel gelesen, in dem die nicht auf OAuth2 basierende REST-Sicherheit von Amazon für AWS erläutert wird. Es handelt sich im Wesentlichen um eine auf privaten Schlüsseln basierende Lösung, bei der Hashes jeder REST-Anforderung generiert und als Sidecars zusammen mit der normalen (unverschlüsselten) Anforderung gesendet werden. Nur der Client und der Server kennen den privaten Schlüssel. Wenn der Server die Anforderung empfängt (die wiederum die normale Anforderung und die Hash-Anforderung enthält), schlägt der Server den privaten Schlüssel des Clients nach und wendet denselben Hash auf die normale Anforderung an vergleicht dann die beiden Hashes.
Das klingt viel komplizierter, komplexer und sicherer als der ROPC von OAuth2! Es sei denn , ich etwas fehlt bin Haupt hier wird OAuth2 ROPC nur sendet client_id, usernameund passwordals Query - String - params ... ganz und gar unsicher! Diese HMAC / Hash-basierte Lösung scheint viel eindrucksvoller und sicherer zu sein.
Die Sache ist, sogar der Autor dieses Artikels fährt fort zu sagen:
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, auf HMAC / Hash basierende Lösung, warum sollte OAuth nach Ansicht des Autors dieses Artikels irgendwann akzeptiert werden? Ich bin so verwirrt.
Antworten:
Die Antwort auf Ihre Frage kann auf Code-, Protokoll- oder Architekturebene erfolgen. Ich werde hier versuchen, die meisten Probleme auf Protokollebene zusammenzufassen, da dies in der Regel für die Vor- und Nachteileanalyse von entscheidender Bedeutung ist. Beachten Sie, dass OAuth2 weit mehr ist als die Berechtigungsnachweise für Ressourcenbesitzer , die gemäß der Spezifikation aus "Legacy- oder Migrationsgründen" als "höheres Risiko als andere Gewährungsarten" gelten. In der Spezifikation wird ausdrücklich angegeben, dass die Clients und Berechtigungsserver Msgstr "SOLLTE die Verwendung dieses Grant - Typs minimieren und wenn möglich andere Grant - Typen verwenden".
Es gibt immer noch viele Vorteile der Verwendung von ROPC gegenüber der Basisauthentifizierung, aber bevor wir darauf eingehen, wollen wir den grundlegenden Protokollunterschied zwischen OAuth2 und der Basisauthentifizierung verstehen. Bitte nehmen Sie mit mir Kontakt auf, wenn ich diese erkläre und später zu ROPC komme.
Die Benutzerauthentifizierung fließt
In der OAuth2-Spezifikation sind vier Rollen definiert. Mit Beispielen sind sie:
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 REST-API zur Verfügung stehen, möglicherweise weit mehr als ein Benutzer ohne Administratorrechte.
OAuth2 ermöglicht auch die Verwendung eines einzelnen Berechtigungsservers mit mehreren Clients und für mehrere Ressourcen. Beispielsweise kann ein Ressourcenserver die Authentifizierung eines Benutzers bei Facebook akzeptieren (der in einem solchen Fall als Autorisierungsserver fungieren kann). Wenn der Benutzer eine Anwendung ausführt (dh den Client), 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 vorlegen kann. Der Ressourcenserver überprüft das Token und akzeptiert es, nachdem überprüft wurde, dass 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 (dh die Facebook-Anmeldeinformationen).
Angenommen, Sie verwalten die Identitäten Ihrer Benutzer (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. Bei der Basisauthentifizierung (oder sogar bei ROPC) gibt der Benutzer dem Client Anmeldeinformationen, die ihn an den Autorisierungsserver senden. 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. Sie möchten jedoch nicht, dass die Anwendung eines Partners (der nicht zu Ihrem Unternehmen gehört) auch nur das Kennwort eines Benutzers kennt. Das ist jetzt ein Sicherheitsproblem. Um dieses Ziel zu erreichen,
Daher würde man mit OAuth2 in solchen Fällen im Idealfall nicht ROPC verwenden, sondern einen anderen, beispielsweise einen Autorisierungscode-Fluss. Dies schützt jede Anwendung davor, die Anmeldeinformationen des Benutzers zu kennen, die nur dem Autorisierungsserver angezeigt werden. Somit gehen die Anmeldeinformationen eines Benutzers nicht verloren. Dieselben Probleme treten bei der Basisauthentifizierung auf, aber im nächsten Abschnitt werde ich erläutern, wie ROPC noch besser ist, da die Anmeldeinformationen des Benutzers vom Client noch nicht in ROPC gespeichert werden müssen, damit die Clients dauerhaft auf sie zugreifen können.
Beachten Sie, dass der Autorisierungsserver den Benutzer beim Aufrufen des Autorisierungsservers auffordern kann, zu bestätigen, dass er dem Client den Zugriff auf die Ressourcen in seinem Namen erlauben 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 in diesem Prozess enthalten ist. Wenn der Benutzer den Client nicht autorisiert, erhält er keinen Zugriff auf die Ressourcen. Auch wenn der Benutzer selbst keinen Zugriff auf die Ressourcen hat, kann der Autorisierungsserver den Zugriff verweigern und kein Token ausstellen.
Bei der Standardauthentifizierung werden sogar der Autorisierungsserver und der Ressourcenserver zu einer einzigen Entität zusammengefasst. Daher möchte der Ressourcenserver den Benutzer autorisieren und fragt die Anmeldeinformationen vom Client ab. Der Client stellt die Anmeldeinformationen bereit, die vom Ressourcenserver zur Authentifizierung des Benutzers verwendet werden. Dies bedeutet, dass für mehrere Ressourcenserver im Wesentlichen Anmeldeinformationen vom Benutzer erforderlich sind.
Token-Ausstellung
Die Clients erhalten Token vom Autorisierungsserver, behalten sie bei sich und greifen auf diese zu, um auf die Ressourcen zuzugreifen (weitere Details zu den Token finden Sie weiter unten). Die Clients kennen das Kennwort des Benutzers nie (in anderen Abläufen als ROPC) und müssen es nicht speichern. Obwohl die Clients das Kennwort des Benutzers kennen, müssen sie es in ROPC nicht speichern, da sie diese Token für den Zugriff auf Ressourcen verwenden. Wenn ein Client bei der Standardauthentifizierung 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 großer Nachteil bei der Verwendung der Standardauthentifizierung, 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 sich darauf bezieht, wie Token ausgegeben werden und wie sie funktionieren. Wenn ein Benutzer dem Autorisierungsserver Anmeldeinformationen bereitstellt (auch in ROPC), kann der Autorisierungsserver einen oder mehrere der beiden Tokentypen erteilen: 1) Zugriffstoken und 2) Aktualisierungstoken.
Zugriffstoken werden an den Ressourcenserver gesendet, der nach der Validierung den Zugriff auf die Ressourcen gewährt. In der Regel haben sie eine kurze Lebensdauer, z. B. 1 Stunde. Aktualisierungstoken werden vom Client an den Autorisierungsserver gesendet, um nach Ablauf ein weiteres Zugriffstoken zu erhalten, das normalerweise eine lange Lebensdauer hat (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 im Token, ob der Zugriff zulässig ist 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. Nun 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 eingeben muss, und dem Client somit ein anderes Zugriffstoken erteilen. Der Client hat jetzt wieder Zugriff auf den Ressourcenserver. Auf diese Weise werden die Clientanwendungen für Facebook und Twitter in der Regel einmal nach Anmeldeinformationen gefragt, und der Benutzer muss keine Anmeldeinformationen mehr eingeben. Diese Anwendungen müssen nie die Anmeldeinformationen des Benutzers kennen und können dennoch bei jedem Start der Anwendung auf Ressourcen zugreifen.
Jetzt kann der Benutzer auf dem Autorisierungsserver (z. B. in seinem Facebook-Benutzerprofil) das Kennwort ändern, ohne dass sich dies auf Clientanwendungen auswirkt. Sie funktionieren alle weiterhin ordnungsgemäß. Wenn der Benutzer ein Gerät verliert, auf dem er bereits eine Anwendung mit Aktualisierungstoken hatte, kann er dem Autorisierungsserver (z. B. Facebook) mitteilen, dass er sich von den Anwendungen "abmelden" soll, die der Autorisierungsserver (z. B. Facebook) durch Nichteinhaltung vorhandener Anwendungen ausführen soll Token aktualisieren und den Benutzer zwingen, erneut Anmeldeinformationen bereitzustellen, 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 Benutzer verfügbar sind, anstatt dass jeder Ressourcenserver eine weitere Lösung implementiert. Der Vorteil liegt also 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 angezeigt wird. Es gibt auch ein umfassendes Bedrohungsmodell für OAuth2 für Entwickler, die die darin enthaltenen Vorschläge verwenden können, um häufige Sicherheitslücken 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. In dieser Antwort habe ich den Vergleich mit der Basisauthentifizierung nicht durchgeführt.
Der letzte große Vorteil von OAuth2 ist, dass das Protokoll standardisiert ist und von mehreren Berechtigungsservern, Clients und Ressourcenservern anerkannt wird. Entwicklern stehen zahlreiche Bibliotheken zur Verfügung, die gewartet werden, damit bei Implementierungen Sicherheitsprobleme auftreten, die Bibliotheken aktualisiert werden und gleichzeitig die Interoperabilität gewährleistet ist.
Fazit
Wenn Sie eine neue Anwendung, IMO, schreiben, ist es aufgrund der damit verbundenen Probleme ideal, sowohl die Standardauthentifizierung als auch ROPC zu vermeiden. Jede Anwendung hat jedoch andere Anforderungen, Fristen, Entwicklerfähigkeiten usw., sodass die Entscheidung von Fall zu Fall fällt. Aber selbst wenn Sie nicht mehr als eine Standardauthentifizierung benötigen, können Sie sich durch Auswahl dieser Option auf eine Architektur einlassen, 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 gibt jedem von ihnen Anmeldeinformationen, stattdessen gibt er sie nur einmal an den Autorisierungsserver weiter, der Token usw. austeilen 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 davon getäuscht werden. Die oben genannten Unterschiede liegen normalerweise auf der Architekturebene, und daher habe ich mich darauf konzentriert, da die Architektur nach der Implementierung am schwierigsten zu ändern ist.
Mit Azure Active Directory B2C Basic , einem Dienst, an dem ich arbeite und der kürzlich für die öffentliche Vorschau freigegeben wurde, können Drittanbieteranwendungen AAD als Autorisierungsserver mit Interoperabilität mit sozialen IDPs (wie Facebook, Google usw.) verwenden. Außerdem können Benutzer ihre eigenen Konten erstellen, anstatt soziale IDPs zu verwenden, und diese können später zu Authentifizierungszwecken verwendet werden. Es gibt auch einige andere Dienste wie diesen (z. B. einen anderen, den ich kenne, ist auth0), mit dessen Hilfe Entwickler Authentifizierung und Benutzerverwaltung für ihre Anwendungen und Ressourcen vollständig auslagern können. Die oben genannten Protokolleigenschaften 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.
quelle
(a) letting the user agent hold just the token instead of the password, (b) allowing a password change without disrupting existing client apps, (c) allowing users log out other sessionsspeziell für Tokenauthentifizierungsflüsse gelten. Weder die Basisauthentifizierung noch die Tokenauthentifizierung erwähnen die Funktionen (b) und (c) in ihren Spezifikationen. Die Implementierung von (b) und (c) scheint für jede Art von Authentifizierung möglich zu sein. Es würde beinhalten, die Kennwörter zu verfolgen (vorzugsweise deren Hashes). Der Vorteil (a) scheint vom weiteren Umfang des Passworts abhängig zu sein.Ich glaube, Sie sind über die Verschlüsselung um GET-Variablen in einer URL falsch informiert
Die einzigen Personen, die die GET-Variablen in einer Anforderung anzeigen können, sind der ursprüngliche Computer 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, werden verschlüsselt.
Die einzige Einschränkung besteht darin, dass der empfangende Server möglicherweise den vollständigen Anforderungspfad abmeldet. Sie haben jedoch die Kontrolle darüber, sodass Sie diese Daten nach Belieben schützen können.
quelle
Die Standardauthentifizierung ist kein guter Weg, um Ihre REST-API zu sichern. Die Gründe dafür habe ich in dieser Antwort erläutert .
Wenn Sie eine REST-API erstellen, implementieren Sie den Ressourcenserver in OAuth2-Begriffen. Alles, was Ihre API tun muss, ist zu überprüfen, ob das mit der Anforderung im Authorization HTTP-Header übergebene Token gültig ist und von einem vertrauenswürdigen Aussteller stammt. Unter diesem Link finden Sie Schritte zum Implementieren der Validierung, wenn keine Bibliothek verfügbar ist.
Wie Ihr Client das Token vom Autorisierungsserver erhält, hängt davon ab, um welchen Client es sich handelt. 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 die Berechtigungscodebewilligung verwenden . Wenn es sich um einen nicht vertrauenswürdigen Client wie eine mobile Anwendung oder eine JavaScript-Anwendung handelt, sollte der implizite Zuschuss verwendet werden .
Für Back-End-Services, die nicht mit einem Ressourcenbesitzer interagieren können, können Sie Client-Anmeldeinformationen gewähren . Für Befehlszeilentools können Sie entweder Clientanmeldeinformationen oder die Kennwortgewährung des Ressourcenbesitzers 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.
quelle
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üsselt zu senden, wenn verschlüsselte Pipes wie Https verwendet werden.
OAuth bietet mehr Funktionen. Verwenden Sie diese, wenn Sie sie benötigen. Für alles andere, z. B. für Bankgeschäfte, ist die Verwendung von Basic Challenge-Response in Ordnung und sicher.
quelle
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 dem amazon (gemäß dem Artikel und den in Ihrer Frage angegebenen Details) eine gültige digitale Signatur erstellt, die dem Empfänger (hier Amazon) Anlass zu der Annahme gibt, dass die Nachricht von einem Bekannten erstellt wurde Absender, dass der Absender nicht leugnen kann, die Nachricht gesendet zu haben ( Authentifizierung und Nicht-Ablehnung)
Welcher Autorisierungsmechanismus verwendet werden soll, hängt mehr oder weniger von Ihrem Anwendungsfall ab.
Nachfolgend finden Sie Informationen zu StackOverflow :
Und hier ist ein weiterer interessanter Artikel , der die beiden miteinander vergleicht.
quelle