OAuth

Für Mediawikis (die von Wikipedia verwendete Software) siehe OAuth -Unterstützung MW: Hilfe: OAuth

OAuth (""OStift AuthOrisation "[1][2]) ist ein offener Standard für den Zugriff DelegationDie Internetnutzer werden häufig als Möglichkeit verwendet, Websites oder Anwendungen auf ihre Informationen auf anderen Websites zu gewähren, ohne ihnen die Passwörter zu geben.[3][4] Dieser Mechanismus wird von Unternehmen wie verwendet, z. Amazonas,[5] Google, Facebook, Microsoft, und Twitter Damit die Benutzer Informationen über ihre Konten mit Anwendungen oder Websites von Drittanbietern teilen können.

Überblick

Im Allgemeinen bietet OAuth Clients im Namen eines Ressourcenbesitzers einen "sicheren delegierten Zugriff" auf Serverressourcen. Es gibt einen Prozess an, der Ressourcenbesitzern zum Genehmigung von Zugriff auf ihre Serverressourcen an Drittanbietern angreift, ohne Anmeldeinformationen bereitzustellen. Speziell entwickelt, um mit zu arbeiten Hypertext Transfer Protocol (Http), OAuth erlaubt im Wesentlichen Zugriff auf Token von einem Autorisierungsserver mit Genehmigung des Ressourcenbesitzers an Drittanbieter-Clients ausgestellt werden. Der Dritte verwendet dann das Zugriffstoken, um auf die vom Ressourcenserver gehosteten geschützten Ressourcen zuzugreifen.[2] Insbesondere OAuth 2.0 bietet spezifische Autorisierungsströme für Webanwendungen, Desktop -Anwendungen, Mobiltelefone und Intelligente Geräte.

  • Authorization flow without Oauth.

    Ein hypothetischer Autorisierungsfluss, bei dem Anmeldeinformationen an eine Anwendung von Drittanbietern geteilt werden. Dies stellt viele Sicherheitsrisiken dar, die durch die Verwendung von OAuth -Autorisierungsströmen verhindert werden können.

  • A high-level overview of Oauth 2.0 authorization flow.

    Ein hochrangiger Überblick über den OAuth 2.0-Fluss. Die Anmeldeinformationen für Ressourcenbesitzer werden nur auf dem Autorisierungsserver verwendet, jedoch nicht auf dem Client (z. B. der App von Drittanbietern).

Geschichte

Das von American Blogger entworfene OAuth -Logo Chris Messina

OAuth begann im November 2006, als Blaine Cook entwickelte die Twitter OpenID Implementierung. In der Zwischenzeit, Magnolie benötigte eine Lösung, damit seine Mitglieder mit OpenIDs autorisieren können Dashboard -Widgets Zugang zu ihrem Service. Kochen, Chris Messina und Larry Halff von Magnolia traf sich mit David Recordon Um mit OpenID mit Twitter und Magnolia zu diskutieren Apis Authentifizierung delegieren. Sie kamen zu dem Schluss, dass es keine offenen Standards für die API -Zugangsdelegation gab.[6]

Die oauth Diskussionsgruppe wurde im April 2007 gegründet, damit die kleine Gruppe von Implementierern den Entwurf für ein offenes Protokoll geschrieben hatte. DeWitt Clinton von Google erfuhr vom OAuth -Projekt und bekundete sein Interesse an der Unterstützung der Bemühungen. Im Juli 2007 entwarf das Team eine erste Spezifikation. Eran Hammer schloss sich den vielen OAuth -Beiträgen an und koordinierte eine formellere Spezifikation. Am 4. Dezember 2007 wurde der endgültige Entwurf von OAuth Core 1.0 veröffentlicht.[7]

Am 73. Internettechnik-Arbeitsgruppe (IETF) Treffen in Minneapolis Im November 2008 eine OAuth Bof Es wurde festgehalten, das Protokoll für weitere Standardisierungsarbeiten in das IETF zu bringen. Die Veranstaltung war gut besucht und es wurde eine große Unterstützung für die offizielle Chartierung einer OAuth -Arbeitsgruppe innerhalb der IETF unterstützt.

Das OAuth 1.0 -Protokoll wurde als RFC 5849 veröffentlicht, eine Information Anfrage für KommentareIm April 2010. Seit dem 31. August 2010 waren alle Twitter -Bewerbungen von Drittanbietern erforderlich, um OAuth zu verwenden.[8]

Das OAuth 2.0 -Framework wurde unter Berücksichtigung zusätzlicher Anwendungsfälle und Erweiterbarkeitsanforderungen veröffentlicht, die aus der breiteren IETF -Community gesammelt wurden. OAuth 2.0 ist jedoch nicht rückwärts kompatibel mit OAuth 1.0. OAuth 2.0 wurde im Oktober 2012 als RFC 6749 und die Nutzung der Bearer -Token als RFC 6750 veröffentlicht.[2][9]

Das OAuth 2.1-Autorisierungsrahmen befindet sich in der Entwurfsbühne und konsolidiert die Funktionalität in der RFCS OAuth 2.0, OAuth 2.0 für native Apps, Beweisschlüssel für den Code-Austausch, OAuth 2.0 für Browser-basierte Apps, OAuth Security Best Current Current Current und Bearer Token Usage.[10]

Sicherheitsprobleme

OAuth 1.0

Am 23. April 2009 a Sitzungsfixierung Sicherheitsfehler im 1.0 -Protokoll wurde bekannt gegeben. Es betrifft den OAuth-Autorisierungsfluss (auch als "3-legierte OAuth") in OAuth Core 1.0 Abschnitt 6.[11] Version 1.0a des OAuth -Kernprotokolls wurde ausgestellt, um dieses Problem zu lösen.[12]

OAuth 2.0

Im Januar 2013 veröffentlichte die Internet Engineering Task Force ein Bedrohungsmodell für OAuth 2.0.[13] Zu den umgestellten Bedrohungen gehört einer "offene Redirector"; Anfang 2014 wurde eine Variante davon unter dem Namen "Covert Redirect" von Wang Jing beschrieben.[14][15][16][17]

OAuth 2.0 wurde unter Verwendung einer formalen Webprotokollanalyse analysiert. Diese Analyse ergab, dass bei Setups mit mehreren Autorisierungsservern, von denen sich eines böswillig verhält, die Verwendung des Autorisierungsservers verwirrt werden und Geheimnisse an den böswilligen Autorisierungsserver weiterleiten können (als Mischanfall).[18] Dies führte zur Schaffung eines neuen Beste aktuelle Praxis Internetentwurf, der einen neuen Sicherheitsstandard für OAuth 2.0 definiert.[19] Unter der Annahme eines Fixes gegen den AS-Mischungsangriff wurde die Sicherheit von OAuth 2.0 unter starken Angreifermodellen unter Verwendung formaler Analyse nachgewiesen.[18]

Eine Implementierung von OAuth 2.0 mit zahlreichen Sicherheitsfehler wurde aufgedeckt.[20]

Im April und Mai 2017 rund eine Million Benutzer von Google Mail (Weniger als 0,1% der Benutzer im Mai 2017) wurden von einem in OAuth ansässigen Phishing-Angriff gezielt und erhielten eine E-Mail, die angeblich von einem Kollegen, einem Arbeitgeber oder einem Freund stammt, der ein Dokument auf Google Docs teilen möchte.[21] Diejenigen, die auf den Link innerhalb der E-Mail geklickt haben, wurden angewiesen, sich anzumelden und ein potenziell böswilliges Programm von Drittanbietern mit dem Namen "Google Apps" zuzulassen, um auf das "E-Mail-Konto, Kontakte und Online-Dokumente" zuzugreifen.[21] Innerhalb "ungefähr eine Stunde",[21] Der Phishing -Angriff wurde von Google gestoppt, der diejenigen beriet, die "Google Apps" auf ihre E -Mail zugefügt hatten, um diesen Zugriff zu widerrufen und ihre Passwörter zu ändern.

Im Entwurf von OAuth 2.1 wurde die Verwendung der PKCE -Erweiterung für native Apps für alle Arten von OAuth -Clients empfohlen, einschließlich Webanwendungen und anderer vertraulicher Kunden, um böswillige Browser -Erweiterungen zur Durchführung von OAuth 2.0 -Code -Injektionsangriffen zu vermeiden.[10]

Verwendet

Facebook's Graph -API Unterstützt nur OAuth 2.0.[22] Google Unterstützt OAuth 2.0 als empfohlener Autorisierungsmechanismus für alle ITS Apis.[23] Microsoft Unterstützt auch OAuth 2.0 für verschiedene APIs und seinen Azure Active Directory -Dienst,[24] mit der viele Microsoft- und Drittanbieter -APIs sichern.

OAuth kann als autorisierender Mechanismus zum Zugang zugesichert werden RSS/Atom Einspeisungen. Der Zugriff auf RSS/Atom -Feeds, die eine Authentifizierung erfordern, war schon immer ein Problem. Zum Beispiel ein RSS -Fütterung von einem gesicherten Google -Site hätte nicht mit nutzungsberechtigten zugreifen können Google Reader. Stattdessen wäre dreibeiniger OAuth verwendet worden, um den RSS-Client von der Google-Website auf den Feed zuzugreifen.

OAuth und andere Standards

OAuth ist ein Service, der ergänzt und unterscheidet sich von OpenID. OAuth hat nichts miteinander zu tun mit EID, was eine Referenzarchitektur für die Authentifizierung ist, kein Standard für die Autorisierung. OAuth ist jedoch direkt mit dem Zusammenhang mit OpenID Connect (OIDC), da OIDC eine Authentifizierungsschicht ist, die auf OAuth 2.0 basiert. OAuth hat auch nichts miteinander zu tun mit Xacml, das ist ein Autorisierungsrichtliniestandard. OAuth kann in Verbindung mit XACML verwendet werden, wobei OAuth für die Einwilligung der Eigentümerschaft und den Zugriffsdelegation verwendet wird, während XACML zur Definition der Autorisierungsrichtlinien verwendet wird (z. B. können Manager Dokumente in ihrer Region anzeigen).

OpenID vis Pseudo-Authentifizierung unter Verwendung von OAuth

OAuth ist ein Genehmigung Protokoll und nicht ein Authentifizierung Protokoll. Die Verwendung von OAuth selbst als Authentifizierungsmethode kann als Pseudo-Authentifizierung bezeichnet werden. Die folgenden Diagramme unterstreichen die Unterschiede zwischen der Verwendung von OpenID (speziell als Authentifizierungsprotokoll) und OAuth zur Autorisierung.

Der Kommunikationsfluss in beiden Prozessen ist ähnlich:

  1. (Nicht abgebildet) Der Benutzer fordert eine Ressource oder eine Site -Anmeldung aus der Anwendung an.
  2. Die Website sieht, dass der Benutzer nicht authentifiziert ist. Es formuliert eine Anfrage für den Identitätsanbieter, codiert sie und sendet sie als Teil einer Umleitungs -URL an den Benutzer.
  3. Der Browser des Benutzers stellt eine Anfrage an die Umleitungs -URL für den Identitätsanbieter, einschließlich der Anfrage der Anwendung
  4. Gegebenenfalls authentifiziert der Identitätsanbieter den Benutzer (möglicherweise indem er ihn nach ihrem Benutzernamen und seinem Passwort bittet)
  5. Sobald der Identitätsanbieter davon überzeugt ist, dass der Benutzer ausreichend authentifiziert ist, verarbeitet er die Anfrage der Anwendung, formuliert eine Antwort und sendet diese an den Benutzer zusammen mit einer Umleitungs -URL zurück zur Anwendung.
  6. Der Browser des Benutzers fordert die Umleitungs -URL an, die zur Anwendung zurückgeht, einschließlich der Antwort des Identitätsanbieters
  7. Die Anwendung dekodiert die Reaktion des Identitätsanbieters und führt entsprechend weiter.
  8. (Nur OAuth) Die Antwort enthält ein Zugriffstoken, mit dem die Anwendung im Namen des Benutzers direkten Zugriff auf die Dienste des Identitätsanbieters erhalten kann.

Der entscheidende Unterschied besteht darin, dass im OpenID Authentifizierung Anwendungsfall, die Antwort des Identitätsanbieters ist eine Behauptung der Identität; Während der Oauth Genehmigung Anwendungsfall ist der Identitätsanbieter auch ein API Der Anbieter und die Antwort des Identitätsanbieters sind ein Zugriffstoken, das dem Antrag möglicherweise im Namen des Benutzers den kontinuierlichen Zugriff auf einige der APIs des Identitätsanbieters gewährt. Das Access -Token fungiert als eine Art "Valet -Schlüssel", den die Anwendung mit ihren Anfragen an den Identitätsanbieter enthalten kann, die nachweisen, dass sie vom Benutzer die Erlaubnis hat, auf diese APIs zuzugreifen.

Da der Identitätsanbieter normalerweise (aber nicht immer) den Benutzer als Teil des Prozesses der Gewährung eines OAuth -Zugriffs -Tokens authentifiziert, ist es verlockend, eine erfolgreiche OAuth -Zugriffsanforderung als Authentifizierungsmethode selbst anzusehen. Da OAuth jedoch nicht mit diesem Anwendungsfall entworfen wurde, kann diese Annahme zu schwerwiegenden Sicherheitsfehler führen.[25]

OpenID vs. pseudo-authentication using OAuth

OAuth und XACML

Xacml ist eine politisch basierte, Attributbasierte Zugriffskontrolle Autorisierungsrahmen. Es bietet:

  • Ein Zugangskontrollarchitektur.
  • Eine politische Sprache, mit der eine breite Palette von Zugangskontrollrichtlinien ausdrückt werden kann, einschließlich Richtlinien, die über OAuth gehandhabte / definiert werden können.
  • Ein Antrags- / Antwortschema zum Senden und Empfangen von Autorisierungsanfragen.

XACML und OAuth können kombiniert werden, um einen umfassenderen Ansatz für die Genehmigung zu erzielen. OAuth bietet keine politische Sprache, mit der die Richtlinien zur Zugriffskontrolle definiert werden können. XACML kann für seine politische Sprache verwendet werden.

Wo sich OAuth auf den delegierten Zugriff (i, der Benutzer, Twitter-Zugriff auf meine Facebook-Wand) und die identitätszentrierte Autorisierung konzentriert, verfolgt XACML einen Attribut-basierten Ansatz, der Attribute des Benutzers, die Aktion, die Ressource und die Ressource berücksichtigen kann Kontext (wer, was, wo, wann, wie). Mit XACML ist es möglich, Richtlinien wie zu definieren, z.

  • Manager können Dokumente in ihrer Abteilung anzeigen
  • Manager können Dokumente bearbeiten, die sie im Entwurfsmodus besitzen

XACML bietet eine feinkörnige Zugriffskontrolle als OAuth. OAuth ist in der Granularität begrenzt auf die grobe Funktionalität (die vom Zieldienst freigelegten Scopes). Infolgedessen ist es häufig sinnvoll, OAuth und XACML zusammen zu kombinieren, wenn OAuth den delegierten Gebrauchsfall und die Einwilligungsverwaltung bereitstellt, und XACML die Berechtigungsrichtlinien für Anwendungen, Prozesse und Daten bereitstellt.

Schließlich kann XACML transparent über mehrere Stapel arbeiten (Apis, Web SSO, ESBs, Hausbanken, Datenbanken ...). OAuth konzentriert sich ausschließlich auf HTTP-basierte Apps.

Kontroverse

Eran Hammer trat von seiner Rolle des Hauptautors für das OAuth 2.0 -Projekt zurück, die aus dem zurückgezogen wurde IETF Arbeitsgruppeund entfernte seinen Namen von der Spezifikation im Juli 2012. Hammer zitierte einen Konflikt zwischen Web- und Unternehmenskulturen als seinen Grund für das Verlassen, und stellte fest, dass IETF eine Community ist, in der "alles um Unternehmensnutzungsfälle" und "nicht einfach zu einfach" geht. "Was jetzt angeboten wird, ist eine Blaupause für ein Autorisierungsprotokoll", bemerkte er, "das ist der unternehmerische Weg", der eine "ganz neue Grenze zum Verkauf von Beratungsdiensten und Integrationslösungen" bereitstellt.[26] Beim Vergleich von OAuth 2.0 mit OAuth 1.0 weist Hammer darauf hin, dass es "komplexer, weniger interoperabler, weniger nützlich, unvollständiger und vor allem weniger sicher" ist. Er erklärt, wie architektonische Veränderungen für 2,0 ungebundene Token von Kunden, alle Unterschriften und Kryptographie auf Protokollebene entfernt und ablaufende Token hinzugefügt haben (weil Token nicht widerrufen werden konnten), während die Verarbeitung der Autorisierung erschwert wurde. Zahlreiche Elemente wurden in der Spezifikation nicht spezifiziert oder unbegrenzt, da "wie die Art dieser Arbeitsgruppe kein Problem zu klein ist, um festzuhalten oder für jede Implementierung offen zu lassen, um zu entscheiden."[26]

David Recordon Später entfernte er seinen Namen auch aus nicht spezifizierten Gründen aus den Spezifikationen. Dick Hardt Übernahm die Rolle des Herausgebers und das Rahmen wurde im Oktober 2012 veröffentlicht.[2]

David Harris, Autor des E -Mail -Kunden Pegasus Mail, hat OAuth 2.0 als "das Frühstück eines Absoluthundes" kritisiert, bei dem Entwickler benutzerdefinierte Module schreiben müssen, die für jeden Dienst spezifisch sind (Google Mail, Microsoft Mail -Dienste usw.) und sich speziell bei ihnen registrieren.[27]

Siehe auch

Verweise

  1. ^ "Offene Autorisierung - Glossar | CSRC". csrc.nist.gov.
  2. ^ a b c d Hardt, Dick (Oktober 2012). "RFC6749 - Das OAuth 2.0 -Autorisierungsrahmen". Internettechnik-Arbeitsgruppe. Archiviert Aus dem Original am 15. Oktober 2012. Abgerufen 10. Oktober 2012.
  3. ^ Whitson, Gordon. "OAuth verstehen: Was passiert, wenn Sie sich bei Google, Twitter oder Facebook bei einer Website anmelden". Lifehacker. Archiviert Aus dem Original am 24. April 2014. Abgerufen 15. Mai 2016.
  4. ^ Henry, Gavin (Januar 2020). "Justin reicher auf Oauth". IEEE -Software. 37 (1): 98–100. doi:10.1109/ms.2019.2949648. ISSN 0740-7459.
  5. ^ "Amazon & Oauth 2.0". Archiviert Aus dem Original am 8. Dezember 2017. Abgerufen 15. Dezember 2017.
  6. ^ "Einführung". oAuth.net. Archiviert Aus dem Original am 21. November 2018. Abgerufen 21. November 2018.
  7. ^ "OAuth Core 1.0". 4. Dezember 2007. Archiviert vom Original am 25. November 2015. Abgerufen 16. Oktober 2014.
  8. ^ Chris Crum (31. August 2010). "Twitter -Apps gehen heute oAuth". WebPronews.com. Archiviert Aus dem Original am 31. Juli 2017. Abgerufen 31. Juli 2017.
  9. ^ Jones, Michael; Hardt, Dick (Oktober 2012). "RFC6750 - Der OAuth 2.0 -Autorisierungsrahmen: Bearer -Token -Nutzung". Internettechnik-Arbeitsgruppe. Archiviert Aus dem Original am 15. Oktober 2012. Abgerufen 10. Oktober 2012.
  10. ^ a b Lodderstedt, Torsten; Hardt, Schwanz; Parecki, Aaron. "Der OAuth 2.1 -Autorisierungsrahmen". Tools.ietf.org. Abgerufen 22. November 2020.
  11. ^ "OAuth Security Advisory: 2009.1". oAuth.net. 23. April 2009. Archiviert vom Original am 27. Mai 2016. Abgerufen 23. April 2009.
  12. ^ "OAuth Core 1.0a". oAuth.net. Archiviert Aus dem Original am 30. Juni 2009. Abgerufen 17. Juli 2009.
  13. ^ Lodderstedt, Torsten; McGloin, Mark; Hunt, Phil (Januar 2013). "RFC6819 - OAuth 2.0 Bedrohungsmodell und Sicherheitsüberlegungen". Internettechnik-Arbeitsgruppe. Archiviert vom Original am 30. Juni 2020. Abgerufen 29. Juni 2020.[RFC: 6819 OAuth 2.0 Bedrohungsmodell und Sicherheitsüberlegungen]. Internettechnik-Arbeitsgruppe. Zugriff auf Januar 2015.
  14. ^ "OAuth Security Advisory: 2014.1" Covert Redirect "". oAuth.net. 4. Mai 2014. Archiviert Aus dem Original am 21. November 2015. Abgerufen 10. November 2014.
  15. ^ "Ernsthafter Sicherheitsfehler in Oauth, OpenID entdeckt". CNET. 2. Mai 2014. Archiviert Aus dem Original am 2. November 2015. Abgerufen 10. November 2014.
  16. ^ "Mathematikstudent erkennt OAuth, OpenID Security Schwachstellen". Phys.org. 3. Mai 2014. Archiviert Aus dem Original am 6. November 2015. Abgerufen 11. November 2014.
  17. ^ "Verdeckte Umleitung". Tetraph. 1. Mai 2014. Archiviert Aus dem Original am 10. März 2016. Abgerufen 10. November 2014.
  18. ^ a b Fett, Daniel; Küster, Ralf; Schmitz, Guido (2016). "Eine umfassende formale Sicherheitsanalyse von OAuth 2.0". Proceedings der ACM SIGSAC -Konferenz 2016 über Computer- und Kommunikationssicherheit - CCS'16. New York, New York, USA: ACM Press: 1204–1215. Arxiv:1601.01229. Bibcode:2016ArXIV160101229f. doi:10.1145/2976749.2978385. ISBN 9781450341394. S2CID 1723789.
  19. ^ Bradley, John; Labunets, Andrey; Lodderstedt, Torsten; Fett, Daniel. "OAuth 2.0 Sicherheit Best aktuelle Praxis". Internettechnik-Arbeitsgruppe. Archiviert Aus dem Original am 17. Januar 2020. Abgerufen 29. Juli 2019.
  20. ^ "Facebook mit OAuth 2.0 und Chrome hacken". 12. Februar 2013. Archiviert Aus dem Original am 23. April 2016. Abgerufen 6. März 2013.
  21. ^ a b c "Google Docs Phishing E -Mail 'kostet minnesota $ 90.000'". BBC News. 8. Mai 2017. Archiviert vom Original am 30. Juni 2020. Abgerufen 29. Juni 2020.
  22. ^ "Authentifizierung - Facebook -Entwickler". Facebook für Entwickler. Archiviert Aus dem Original am 23. Januar 2014. Abgerufen 5. Januar 2020.
  23. ^ "Verwenden von OAuth 2.0 zum Zugriff auf Google APIs | Google Identity Platform". Google -Entwickler. Archiviert Aus dem Original am 4. Januar 2020. Abgerufen 4. Januar 2020.
  24. ^ "V2.0 Protokolle - OAuth 2.0 Autorisierungscodefluss". Microsoft Docs. Archiviert vom Original am 29. Juni 2020. Abgerufen 29. Juni 2020.
  25. ^ "Endbenutzerauthentifizierung mit OAuth 2.0". oAuth.net. Archiviert Aus dem Original am 19. November 2015. Abgerufen 8. März 2016.
  26. ^ a b Hammer, Eran (28. Juli 2012). "OAuth 2.0 und der Weg zur Hölle". Huenivers. Archiviert von das Original am 25. März 2013. Abgerufen 17. Januar 2018.
  27. ^ Harris, David (Oktober 2021). "Pegasus Mail und Mercury Developer News". Pegasus Mail.

Externe Links