Inhaber des Berechtigungsscheins

Offener Standard für die Autorisierung

Für die OAuth-Unterstützung von MediaWiki (die von Wikipedia verwendete Software) siehe mw:Help:OAuth

OAuth (kurz für Open Authorization ^{[1] [2]} ) ist ein offener Standard für die Zugriffsdelegierung, der häufig als Möglichkeit für Internetnutzer verwendet wird, Websites oder Anwendungen Zugriff auf ihre Informationen auf anderen Seiten zu gewähren. Websites, ohne ihnen jedoch die Passwörter zu geben. ^{[3] [4]} Dieser Mechanismus wird von Unternehmen wie Amazon, ^[5] Google, Meta Platforms, Microsoft und Twitter verwendet, um es Nutzern zu ermöglichen, Informationen über ihre Konten mit Anwendungen oder Websites von Drittanbietern zu teilen.

Im Allgemeinen bietet das OAuth-Protokoll Ressourcenbesitzern die Möglichkeit, eine Clientanwendung bereitzustellen mit sicherem delegiertem Zugriff auf Serverressourcen. Sie gibt einen Prozess an, mit dem Ressourcenbesitzer den Zugriff von Drittanbietern auf ihre Serverressourcen autorisieren können, ohne Anmeldeinformationen anzugeben. OAuth wurde speziell für die Arbeit mit HTTP (Hypertext Transfer Protocol) entwickelt und ermöglicht im Wesentlichen die Ausgabe von Zugriffstoken an Clients von Drittanbietern durch einen Autorisierungsserver mit Genehmigung des Ressourcenbesitzers. Der Drittanbieter verwendet dann das Zugriffstoken, um auf die geschützten Ressourcen zuzugreifen, die vom Ressourcenserver gehostet werden. ^[2]

Geschichte

OAuth begann im November 2006, als Blaine Cook eine OpenID-Implementierung für Twitter entwickelte. In der Zwischenzeit benötigte Ma.gnolia eine Lösung, die es seinen Mitgliedern mit OpenIDs ermöglichte, Mac OS X Dashboard-Widgets für den Zugriff auf ihren Dienst zu autorisieren. Cook, Chris Messina und Larry Halff von Magnolia trafen sich mit David Recordon , um die Verwendung von OpenID mit den Twitter- und Magnolia-APIs zum Delegieren der Authentifizierung zu erörtern. Sie kamen zu dem Schluss, dass es keine offenen Standards für die Delegierung von API-Zugriffen gibt. ^[6]

Die OAuth-Diskussionsgruppe wurde im April 2007 für eine kleine Gruppe von Implementierern gegründet, um den Entwurf eines Vorschlags für ein offenes Protokoll zu verfassen. DeWitt Clinton von Google erfuhr von dem OAuth-Projekt und bekundete sein Interesse, die Bemühungen zu unterstützen. Im Juli 2007 entwarf das Team ein erstes Lastenheft. Eran Hammer schloss sich den vielen OAuth-Beiträgen an und koordinierte sie, um eine formalere Spezifikation zu erstellen. Am 4. Dezember 2007 wurde der endgültige Entwurf von OAuth Core 1.0 veröffentlicht. ^[7]

Auf dem 73. Treffen der Internet Engineering Task Force (IETF) in Minneapolis im November 2008 wurde ein OAuth-Vorstandstreffen abgehalten, um die Aufnahme des Protokolls in die IETF für weitere Standardisierungsarbeiten zu erörtern. Die Veranstaltung war gut besucht und es gab breite Unterstützung für die formelle Gründung einer OAuth-Arbeitsgruppe innerhalb der IETF.

Das OAuth 1.0-Protokoll wurde im April 2010 als RFC 5849, eine informative Bitte um Kommentare, veröffentlicht. Seit dem 31. August 2010 sind alle Twitter-Anwendungen von Drittanbietern verpflichtet, OAuth zu verwenden. ^[8]

Das OAuth 2.0-Framework wurde unter Berücksichtigung zusätzlicher Anwendungsfälle und Erweiterbarkeitsanforderungen veröffentlicht, die von der breiteren IETF-Community gesammelt wurden. Obwohl OAuth 2.0 auf der OAuth 1.0-Bereitstellungsumgebung aufbaut, ist es nicht abwärtskompatibel mit OAuth 1.0. OAuth 2.0 wurde im Oktober 2012 als RFC 6749 und die Bearer Token Usage Specification als RFC 6750 veröffentlicht, beide Standards verfolgen Requests for Comments. ^{[2] [9]}

Im November 2024 ist der Entwurf des OAuth 2.1 Authorization Framework in Arbeit. Es konsolidiert die Funktionalität in RFCs OAuth 2.0, OAuth 2.0 für native Apps, Proof Key für Code Exchange, OAuth 2.0 für browserbasierte Apps, OAuth Security Best Current und Bearer Token Usage. ^[10]

Sicherheitslücken

OAuth 1.0

Am 23. April 2009 wurde eine Sicherheitslücke im Protokoll 1.0 bei der Sitzungsfixierung bekannt gegeben. Es wirkt sich auf den OAuth-Autorisierungsfluss (auch als "3-legged OAuth" bezeichnet) in OAuth Core 1.0 Abschnitt 6 aus. ^[11] Version 1.0a des OAuth Core-Protokolls wurde veröffentlicht, um dieses Problem zu beheben. ^[12]

OAuth 2.0

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

OAuth 2.0 wurde mit Hilfe einer formalen Webprotokollanalyse analysiert. Diese Analyse ergab, dass Clients in Setups mit mehreren Autorisierungsservern, von denen sich einer böswillig verhält, über den zu verwendenden Autorisierungsserver verwirrt werden und Geheimnisse an den bösartigen Autorisierungsserver weiterleiten können (AS Mix-Up Attack). ^[18] Dies veranlasste die Erstellung eines neuen Best-Practice-Internetentwurfs, der einen neuen Sicherheitsstandard für OAuth 2.0 definieren soll. ^[19] Unter der Annahme, dass es einen Fix gegen die AS Mix-Up Attack gibt, wurde die Sicherheit von OAuth 2.0 unter starken Angreifermodellen mit formaler Analyse nachgewiesen. ^[18]

Eine Implementierung von OAuth 2.0 mit zahlreichen Sicherheitslücken wurde aufgedeckt. ^[20]

Im April und Mai 2017 wurden etwa eine Million Nutzer von Gmail (weniger als 0,1 % der Nutzer im Mai 2017) Ziel eines OAuth-basierten Phishing-Angriffs, der eine E-Mail erhielt, die angeblich von einem Kollegen, Arbeitgeber oder Freund stammte, der ein Dokument in Google Docs teilen wollte. ^[21] Diejenigen, die auf den Link in der E-Mail klickten, wurden angewiesen, sich anzumelden und einem potenziell bösartigen Drittanbieterprogramm namens "Google Apps" den Zugriff auf ihr "E-Mail-Konto, ihre Kontakte und Online-Dokumente" zu ermöglichen. ^[21] Innerhalb von "ungefähr einer Stunde" ^[21] wurde der Phishing-Angriff von Google gestoppt, das denjenigen, die "Google Apps" Zugriff auf ihre E-Mails gewährt hatten, riet, diesen Zugriff zu widerrufen und ihre Passwörter zu ändern.

Im Entwurf von OAuth 2.1 wurde die Verwendung der PKCE-Erweiterung (RFC 7636) für native Apps für alle Arten von OAuth empfohlen Clients, einschließlich Webanwendungen und anderer vertraulicher Clients, um zu verhindern, dass bösartige Browsererweiterungen OAuth 2.0-Code-Injection-Angriffe durchführen. ^[10]

Typen

Das OAuth-Framework gibt mehrere Grant-Typen für unterschiedliche Anwendungsfälle an. Einige der gebräuchlichsten OAuth-Gewährungstypen sind: ^[22]

• Autorisierungscode
PKCE-Client-Anmeldeinformationen
• Device Code
• Refresh Token
• Resource Owner Password Credentials (ROPC)

Verwendet

die

Graph-API von Facebook unterstützt nur OAuth 2.0. ^[23] Google unterstützt OAuth 2.0 als empfohlenen Autorisierungsmechanismus für alle seine APIs. ^[24] Microsoft unterstützt auch OAuth 2.0 für verschiedene APIs und seine Azure Active Directory-Dienst ^[25], der zum Sichern vieler APIs von Microsoft und Drittanbietern verwendet wird.

OAuth kann als Autorisierungsmechanismus für den Zugriff auf gesicherte RSS/Atom-Feeds verwendet werden. Der Zugriff auf RSS/ATOM-Feeds, die eine Authentifizierung erfordern, war schon immer ein Problem. Beispielsweise konnte nicht mit Google Reader auf einen RSS-Feed von einer gesicherten Google-Website zugegriffen werden. Stattdessen wäre dreibeiniger OAuth verwendet worden, um diesen RSS-Client für den Zugriff auf den Feed von der Google-Website zu autorisieren.

Freie Software-Client-Implementierungen des OAuth2-Protokolls, wie z. B. die Erweiterung LibreOfficeOAuth2OOo, ermöglichen Ihnen den Zugriff auf entfernte Ressourcen (z. B. über die Google API oder die Microsoft Graph API und OAuth 2.0) und möglicherweise sogar mit der Sprache LibreOffice Basic. Dies macht es sehr einfach, HTTP-Anfragen, die das OAuth 2.0-Protokoll unterstützen, in LibreOffice-Makros zu schreiben und zu verwenden.

OAuth und andere Standards

OAuth ist ein Dienst, der OpenID ergänzt und sich von OpenID unterscheidet. OAuth hat nichts mit OATH zu tun, bei dem es sich um eine Referenzarchitektur für die Authentifizierung und nicht um einen Standard für die Autorisierung handelt. OAuth steht jedoch in direktem Zusammenhang mit OpenID Connect (OIDC), da OIDC eine Authentifizierungsschicht ist, die auf OAuth 2.0 aufbaut. OAuth hat auch nichts mit XACML zu tun, einem Standard für Autorisierungsrichtlinien. OAuth kann in Verbindung mit XACML verwendet werden, wobei OAuth für die Besitzerlaubnis und die Zugriffsdelegierung verwendet wird, während XACML zum Definieren der Autorisierungsrichtlinien verwendet wird (z. B. können Manager Dokumente in ihrer Region anzeigen).

OpenID im Vergleich zur Pseudoauthentifizierung mit OAuth

OAuth ist ein Autorisierungsprotokoll und kein Authentifizierungsprotokoll. Die Verwendung von OAuth allein als Authentifizierungsmethode kann als Pseudoauthentifizierung bezeichnet werden. ^[26] Die folgenden Diagramme verdeutlichen die Unterschiede zwischen der Verwendung von OpenID (speziell als Authentifizierungsprotokoll entwickelt) und OAuth für die Autorisierung.

Der Kommunikationsfluss in beiden Prozessen ist ähnlich:

1. (Nicht abgebildet) Der Benutzer fordert eine Ressourcen- oder Site-Anmeldung von der Anwendung an.
2. Die Website erkennt, dass der Benutzer nicht authentifiziert ist. Er formuliert eine Anforderung an 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 des Identitätsanbieters, einschließlich der Anfrage der Anwendung
.
4. Falls erforderlich, authentifiziert der Identitätsanbieter den Benutzer (z. B. indem er ihn nach seinem Benutzernamen und Passwort fragt).
5. Sobald der Identitätsanbieter davon überzeugt ist, dass der Benutzer ausreichend authentifiziert ist, bearbeitet er die Anfrage der Anwendung. formuliert eine Antwort und sendet diese zusammen mit einer Umleitungs-URL zurück an die 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 decodiert die Antwort des Identitätsanbieters und fährt entsprechend fort.
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 Anwendungsfall der OpenID-Authentifizierung die Antwort des Identitätsanbieters eine Identitätsbestätigung ist, während im Anwendungsfall der OAuth-Autorisierung der Identitätsanbieter auch ein API-Anbieter ist und die Antwort des Identitätsanbieters ein Zugriffstoken ist, das der Anwendung möglicherweise kontinuierlichen Zugriff auf einen Teil der Identität gewährt APIs des Anbieters im Namen des Benutzers. Das Zugriffstoken fungiert als eine Art "Valet-Schlüssel", den die Anwendung in ihre Anforderungen an den Identitätsanbieter aufnehmen kann, um zu beweisen, dass sie über die Berechtigung des Benutzers zum Zugriff auf diese APIs verfügt.

Da der Identitätsanbieter den Benutzer in der Regel (aber nicht immer) im Rahmen des Prozesses der Gewährung eines OAuth-Zugriffstokens authentifiziert, ist es verlockend, eine erfolgreiche OAuth-Zugriffstokenanforderung selbst als Authentifizierungsmethode zu betrachten. Da OAuth jedoch nicht für diesen Anwendungsfall entwickelt wurde, kann diese Annahme zu großen Sicherheitslücken führen. ^[27]

OAuth und XACML

XACML ist ein richtlinienbasiertes, attributbasiertes Autorisierungsframework für die Zugriffskontrolle. Es bietet:

• Eine Zugriffskontrollarchitektur.
• Eine Richtliniensprache, mit der ein breites Spektrum von Zugriffen ausgedrückt werden kann Kontrollrichtlinien, einschließlich Richtlinien, die Einwilligungen verwenden können, die über OAuth behandelt / definiert wurden.
• Ein Anforderungs-/Antwortschema zum Senden und Empfangen von Autorisierungsanforderungen.

XACML und OAuth können kombiniert werden, um einen umfassenderen Ansatz für die Autorisierung zu bieten. OAuth stellt keine Richtliniensprache bereit, mit der Zugriffssteuerungsrichtlinien definiert werden können. XACML kann für die Richtliniensprache verwendet werden.

Während sich OAuth auf delegierten Zugriff (ich, der Benutzer, gewähre Twitter Zugriff auf meine Facebook-Pinnwand) und identitätszentrierte Autorisierung konzentriert, verfolgt XACML einen attributbasierten Ansatz, der Attribute des Benutzers, der Aktion, der Ressource und des Kontexts (wer, was, wo, wann, wie) berücksichtigen kann. Mit XACML ist es möglich, Richtlinien zu definieren, wie z. B

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

XACML bietet eine feiner abgestufte Zugriffskontrolle als OAuth. OAuth ist in der Granularität auf die grobe Funktionalität (die Bereiche) beschränkt, die vom Zieldienst verfügbar gemacht werden. Daher ist es oft sinnvoll, OAuth und XACML miteinander zu kombinieren, wobei OAuth den delegierten Zugriffsanwendungsfall und die Einwilligungsverwaltung bereitstellt und XACML die Autorisierungsrichtlinien bereitstellt, die für die Anwendungen, Prozesse und Daten funktionieren.

Zu guter Letzt kann XACML transparent über mehrere Stacks hinweg arbeiten (APIs, Web-SSO, ESBs, selbst entwickelte Apps, Datenbanken ...). OAuth konzentriert sich ausschließlich auf HTTP-basierte Apps.

Kontroverse

Eran Hammer trat im Juli 2012 von seiner Rolle als Hauptautor des OAuth 2.0-Projekts zurück, zog sich aus der IETF-Arbeitsgruppe zurück und entfernte seinen Namen aus der Spezifikation. Hammer nannte einen Konflikt zwischen Web- und Unternehmenskulturen als Grund für seinen Austritt und merkte an, dass die IETF eine Gemeinschaft ist, die "Alles über Enterprise Use Cases" und "nicht in der Lage, einfach zu sein". "Was jetzt angeboten wird, ist eine Blaupause für ein Autorisierungsprotokoll", bemerkte er, "das ist der Weg für Unternehmen", der eine "völlig neue Grenze für den Verkauf von Beratungsdiensten und Integrationslösungen" bietet. ^[28] Beim Vergleich von OAuth 2.0 mit OAuth 1.0 weist Hammer darauf hin, dass es "komplexer, weniger interoperabel, weniger nützlich, unvollständiger und vor allem weniger sicher" geworden ist. Er erklärt, wie architektonische Änderungen für ungebundene Token der Version 2.0 von Clients vorgenommen, alle Signaturen und Kryptografie auf Protokollebene entfernt und ablaufende Token hinzugefügt wurden (da Token nicht widerrufen werden konnten), während die Verarbeitung der Autorisierung erschwert wurde. Zahlreiche Punkte wurden in der Spezifikation nicht spezifiziert oder unbegrenzt gelassen, denn "wie es in der Natur dieser Arbeitsgruppe liegt, ist kein Thema zu klein, um es zu lösen oder für jede Implementierung offen zu lassen, um zu entscheiden." ^[28]

David Recordon entfernte später auch seinen Namen aus nicht näher bezeichneten Gründen aus den Spezifikationen. ^{[ Zitat erforderlich ]} Dick Hardt übernahm die Rolle des Herausgebers, und das Framework wurde im Oktober 2012 veröffentlicht. ^[2]

David Harris, Autor des E-Mail-Clients Pegasus Mail, hat OAuth 2.0 als "absolutes Hundefrühstück" kritisiert, das von Entwicklern verlangt, benutzerdefinierte Module zu schreiben, die für jeden Dienst (Gmail, Microsoft Mail-Dienste usw.) spezifisch sind, und sich speziell bei ihnen zu registrieren. ^[29]

Siehe auch

Referenzen

Externe Links