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:
- Ressourceneigentümer: Der Benutzer, der Zugriff auf eine Ressource hat, z. B. in Ihrem Fall, können verschiedene Benutzer unterschiedliche Zugriffsberechtigungen für die REST-API haben.
- Der Client: In der Regel die Anwendung, die der Benutzer verwendet, und die Zugriff auf die Ressource benötigt, um dem Benutzer Dienste bereitzustellen.
- Ressourcenserver: die REST-API in Ihrem Fall; und
- 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 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.