OAuth (Open Aut­ho­riza­ti­on)

Heut­zu­ta­ge verwenden wir zahl­rei­che Webseiten, Programme und mobile Apps, um unser privates und be­ruf­li­ches Leben einfacher oder kom­for­ta­bler zu gestalten. An­ge­sichts dieser großen Vielfalt an Tools ist es in­zwi­schen für viele Menschen normal geworden, die Inhalte einer An­wen­dungs­web­site (zum Beispiel Instagram) auch auf einer anderen Website (bei­spiels­wei­se Facebook) zu nutzen – also platt­form­über­grei­fend zu agieren. Da bei diesen Vorgängen aber eine Menge per­sön­li­cher Daten über­tra­gen werden, stellt sich die Frage nach der Si­cher­heit der eigenen Pri­vat­sphä­re. Das Au­to­ri­sie­rungs­pro­to­koll OAuth soll das Risiko für un­be­fug­ten Da­ten­miss­brauch mindern. Kann es dieser Aufgabe gerecht werden?

OAuth, kurz für „Open Aut­ho­riza­ti­on“, ist ein offenes Stan­dard­pro­to­koll, das eine sichere API-Au­to­ri­sie­rung er­mög­licht. Der Pro­gram­mie­rer-Fach­be­griff API (kurz für „Ap­pli­ca­ti­on Pro­gramming Interface“) be­zeich­net in diesem Zu­sam­men­hang eine Schnitt­stel­le, die als Da­ten­über­mitt­ler zwischen ver­schie­de­nen An­wen­dun­gen, Be­nut­zer­ober­flä­chen oder Webseiten fungiert. Eine Au­to­ri­sie­rung solcher von APIs durch­ge­führ­ten Da­ten­über­mitt­lun­gen ist deshalb er­for­der­lich, weil ohne sie das Risiko besteht, dass unbefugte Dritte die Daten abfangen und für ihre Zwecke miss­brau­chen.

Das heißt: Soll eine App zum Beispiel im Namen des Nutzers auf Facebook posten (also auf das API von Facebook zugreifen), muss sie eine Erlaubnis dieses Nutzers vorweisen können. Ebenso benötigt eine Anwendung die Vollmacht des Nutzers, um seine Pro­fil­in­for­ma­tio­nen aus einem anderen Dienst ziehen zu können. Mittels OAuth kann der Nutzer solch eine Vollmacht (Au­to­ri­sie­rung) erteilen, ohne der au­to­ri­sier­ten Anwendung selbst seinen Be­nut­zer­na­men und sein Passwort mitteilen zu müssen – er behält also die volle Kontrolle über seine Daten.

Anbieter wie Google, Twitter und Facebook können OAuth im Um­kehr­schluss dazu nutzen, ihre Produkte und Dienst­leis­tun­gen flexibler und zugleich sicherer zu gestalten, etwa mittels Single-Sign-On-Lösungen. Und auch Amazon und Microsoft zählen in­zwi­schen zum Kreis großer Un­ter­neh­men, die OAuth als Standard zur Zu­griffs­de­le­gie­rung für ihre Dienst­leis­tun­gen nutzen.

Das nicht rück­wärts­kom­pa­ti­ble OAuth2 (auch „OAuth 2.0“ genannt) wurde im Oktober 2012 als voll­stän­di­ge Über­ar­bei­tung von OAuth ver­öf­fent­licht und hat selbiges in­zwi­schen wei­test­ge­hend abgelöst. So un­ter­stützt die Graph-API von Facebook nur noch das neue Protokoll als Au­to­ri­sie­rungs­stan­dard. Es dient der Au­then­ti­fi­zie­rungs­schicht OpenID Connect (OIDC) als Grundlage.

Prin­zi­pi­ell ist die Aufgabe von OAuth2 dieselbe wie die seines Vor­gän­gers: mittels API-Au­to­ri­sie­rung dem Nutzer mehr Fle­xi­bi­li­tät bei gleich­zei­tig hoher Si­cher­heit zu er­mög­li­chen. Jedoch wurden zahl­rei­che Schwächen des ur­sprüng­li­chen Pro­to­kolls behoben, die das Coding und die Im­ple­men­tie­rung umso schwie­ri­ger machten, je komplexer die Systeme von Facebook, Twitter und anderen API-Be­trei­bern im Laufe der Zeit wurden.

Abgesehen von einer gänzlich ver­än­der­ten Ter­mi­no­lo­gie ist die wich­tigs­te Neuerung von OAuth2, dass es im Gegensatz zu seinem Vorgänger keine kryp­to­gra­fi­schen Si­gna­tu­ren mehr für jede Maschine-zu-Maschine-Kom­mu­ni­ka­ti­on im Pro­to­koll­ab­lauf verlangt. Das er­leich­tert die Anwendung und Er­wei­te­rung des Pro­to­kolls ungemein. Es bedeutet aber auch, dass das neue Protokoll technisch gesehen weniger sicher ist – ein Fakt, der OAuth2 einiges an Kritik ein­brach­te.

Open Aut­ho­riza­ti­on 2.0 wurde außerdem um stärker dif­fe­ren­zier­te Ge­neh­mi­gungs­pro­zes­se (Grant Types) ergänzt und die Per­for­mance des Pro­to­kolls ver­bes­sert. Das haben die Ent­wick­ler dadurch erreicht, dass OAuth2 nicht mehr bei jedem Kom­mu­ni­ka­ti­ons­schritt nach den Zu­gangs­da­ten des Nutzers (Resource Owner) fragt, sondern nur bei der erst­ma­li­gen Au­to­ri­sie­rung der je­wei­li­gen Anwendung (Client). Eine weitere nen­nens­wer­te Neuerung sind Access-Token mit kürzerer Gül­tig­keit, die es einem Dienst (Resource Server) er­leich­tern, erteilte Au­to­ri­sie­run­gen wieder zu­rück­zu­neh­men. Zudem kann der Nutzer unter OAuth2 selbst ent­schei­den, welche Be­rech­ti­gun­gen (scope) er einer Anwendung zugesteht.

Vor allem beim Thema Single-Sign-on (SSO) wird OAuth gern in einem Atemzug mit OpenID und SAML genannt. Zwar geht es bei allen genannten Konzepten um die ver­läss­li­che Ve­ri­fi­zie­rung von Nut­zer­iden­ti­tä­ten, dennoch gibt es große Un­ter­schie­de zwischen den drei.

OpenID (kurz für „Open Iden­ti­fi­ca­ti­on“) ist ein offenes Protokoll: Wenn ein Nutzer sich einen OpenID-Account erstellt, kann er sich mit diesem via Token bei anderen Diensten und An­wen­dun­gen anmelden, die ebenfalls OpenID un­ter­stüt­zen. Ein gutes Beispiel hierfür ist der Button „Mit Google anmelden“, den man in­zwi­schen auf vielen Webseiten findet und der ein Single-Sign-on-Verfahren über den Google-Account des Nutzers zulässt.

Somit ist OpenID im Gegensatz zu OAuth streng­ge­nom­men kein Au­to­ri­sie­rungs-, sondern ein Au­then­ti­fi­zie­rungs­stan­dard. Al­ler­dings sind die beiden Pro­to­kol­le seit 2014 eng mit­ein­an­der verknüpft: OAuth 2.0 ist nämlich die Grundlage, auf der die neue Version von OpenID, genannt OpenID Connect (OIDC), aufbaut. OAuth2 erlaubt den ver­schie­de­nen Arten von An­wen­dun­gen (Clients), die Identität des Nutzers über die Au­then­ti­fi­zie­rung durch einen Au­to­ri­sie­rungs­ser­ver zu über­prü­fen – und darüber hinaus, weitere grund­le­gen­de In­for­ma­tio­nen über ihn ein­zu­ho­len. Im Gegenzug wird das Protokoll um alle not­wen­di­gen Funk­tio­nen für Login und Single-Sign-on ergänzt. OpenID Connect ist zudem um optionale Funk­tio­nen er­wei­ter­bar, bei­spiels­wei­se Session-Ma­nage­ment und die Ver­schlüs­se­lung von Iden­ti­täts­da­ten.

Die offene und XML-basierte Security Assertion Markup Language (kurz: SAML) verbindet ge­wis­ser­ma­ßen die Ei­gen­schaf­ten der beiden vor­an­ge­gan­ge­nen Konzepte. Bei ihr handelt es sich nämlich sowohl um einen Standard für die Au­then­ti­fi­zie­rung als auch für die Au­to­ri­sie­rung. SAML ähnelt in seiner Funk­ti­ons­wei­se OpenID und kommt ebenfalls bei Single-Sign-on-Verfahren zum Einsatz.

Um die Funk­ti­ons­wei­se des OAuth2-Pro­to­kolls zu verstehen, ist eine Übersicht über die darin de­fi­nier­ten Rollen und Ge­neh­mi­gungs­pro­zes­se hilfreich.

OAuth2 un­ter­schei­det vier Rollen:

• Resource Owner (auch: User, Nutzer): eine Entität, die einem Client Zugriff auf seine ge­schütz­ten Daten (auch: Res­sour­cen) gewährt.
• Resource Server (auch: Dienst): ein Server, auf dem die ge­schütz­ten Daten des Resource Owners ge­spei­chert sind.
• Client (auch: Dritter, Third-Party): eine Desktop-, Web- oder Mobile-Anwendung, die auf die ge­schütz­ten Daten des Resource Owners zugreifen will.
• Aut­ho­riza­ti­on Server: ein Server, der den Resource Owner au­then­ti­fi­ziert und einen zeitlich be­grenz­ten Access-Token für einen von ihm de­fi­nier­ten An­wen­dungs­be­reich (scope) ausstellt. Aut­ho­riza­ti­on Server und Resource Server werden in der Praxis häufig zusammen betrieben und dann auch als OAuth-Server be­zeich­net.

Weiterhin wird zwischen vier vor­de­fi­nier­ten Ge­neh­mi­gungs­pro­zes­sen (Grant Types) un­ter­schie­den, die in ver­schie­de­nen An­wen­dungs­fäl­len zum Einsatz kommen:

• Au­to­ri­sie­rungs­code (Aut­ho­riza­ti­on Code): Der Client bittet den Resource Owner, sich beim Aut­ho­riza­ti­on Server ein­zu­log­gen. Daraufhin wird der Resource Owner zusammen mit einem Au­to­ri­sie­rungs­code zum Client zu­rück­ge­lei­tet. Im Austausch für diesen Code stellt der Aut­ho­riza­ti­on Server einen Access-Token für den Client aus.
• Implizite Au­to­ri­sie­rung (Implicit Aut­ho­riza­ti­on): Dieser Ge­neh­mi­gungs­pro­zess ähnelt stark der Be­rech­ti­gung per Au­to­ri­sie­rungs­code, ist aber weniger komplex, da der Aut­ho­riza­ti­on Server den Access-Token direkt ausstellt.
• Pass­wort­frei­ga­be durch den Resource Owner (Resource Owner Password Cre­den­ti­als): Hierbei vertraut der Resource Owner dem Client seine Zu­gangs­da­ten direkt an, was dem Grund­prin­zip von OAuth zwar wei­test­ge­hend zu­wi­der­läuft, aber für den Resource Owner weniger Aufwand bedeutet.
• Client-Be­rech­ti­gung (Client Cre­den­ti­als): Dieser besonders simple Ge­neh­mi­gungs­pro­zess kommt dann zum Einsatz, wenn der Client auf Daten zugreifen will, die keinen Besitzer haben oder für die keine Au­to­ri­sie­rung er­for­der­lich ist.

Benötigt der Client künftig erneut Zugang zu den ge­schütz­ten Daten des Resource Owners, kann er einen zwar zeitlich be­grenz­ten, aber deutlich lang­le­bi­ge­ren Refresh-Token nutzen, um beim Aut­ho­riza­ti­on Server einen neuen Access-Token an­zu­fra­gen. Dabei ist keine erneute Au­to­ri­sie­rung durch den Resource Owner er­for­der­lich.

Konkrete Beispiele für den OAuth2-Pro­to­koll­ab­lauf liefern die sozialen Netzwerke Pinterest und Facebook. So bietet Pinterest die Option, Kontakte aus Facebook-Freun­des­lis­ten zu im­por­tie­ren. Dafür benötigt Pinterest Zugriff auf den je­wei­li­gen Account und die dort hin­ter­leg­ten In­for­ma­tio­nen. Aus Gründen der Da­ten­si­cher­heit wäre es jedoch nicht ratsam, den Be­nut­zer­na­men und das Passwort für Facebook an Pinterest wei­ter­zu­ge­ben – schließ­lich hätte Pinterest dann jederzeit un­ein­ge­schränk­ten Zugang zu allen Daten und Funk­tio­nen des Facebook-Accounts. Damit Pinterest trotzdem auf die be­nö­tig­ten Facebook-Daten zugreifen kann, kommt OAuth2 zum Einsatz:

1. Zunächst loggt man sich in seinen Pinterest-Account ein und navigiert im Be­nut­zer­pro­fil zu den Ein­stel­lun­gen.
2. In der Me­nü­leis­te „Soziale Netzwerke“ schiebt man nun den Regler neben „Facebook“ auf „Ja“.
3. Pinterest bittet nun darum, sich bei Facebook ein­zu­log­gen und die Pinterest-App zu be­stä­ti­gen. Diese Handlung gilt als Au­to­ri­sie­rungs­ge­neh­mi­gung.
4. Pinterest fordert einen Access-Token beim Aut­ho­riza­ti­on Server von Facebook an und nutzt diesen an­schlie­ßend, um auf die ge­schütz­ten Daten auf dem Resourcer Server zu­zu­grei­fen.
5. Die im­por­tier­ten Facebook-Freunde werden nun auch im Pinterest-Account angezeigt.

Dass auch ein für den Schutz per­sön­li­cher Daten kon­zi­pier­tes System wie OAuth nicht hun­dert­pro­zen­tig perfekt sein kann, zeigte sich bereits im April 2009, als im Au­then­ti­fi­zie­rungs­ab­lauf des Pro­to­kolls eine Si­cher­heits­lü­cke entdeckt wurde. Wie bei vielen anderen solcher Systeme ist auch Phishing ein ständiges Risiko: So wurden zwischen April und Mai 2017 eine Million Gmail-User Opfer einer OAuth-basierten Phishing-Attacke. In einer be­trü­ge­ri­schen E-Mail waren sie darum gebeten worden, ihre Au­to­ri­sie­rung über ein ge­fälsch­tes Interface zu erteilen, um einer an­geb­li­chen Anwendung namens „Google Apps“ Zugriff auf ihre Account-Daten zu er­mög­li­chen.

Die Ent­wick­lung der Nach­fol­ger­ver­si­on OAuth2 sollte daher nicht nur die Im­ple­men­tie­rung des zunehmend komplexen Pro­to­kolls er­leich­tern, sondern auch seine Si­cher­heit erhöhen. Im Oktober 2012 kamen die damit ver­bun­de­nen Be­mü­hun­gen zu einem finalen Ergebnis – jedoch ohne eine Absegnung der­je­ni­gen Ent­wick­ler, die damals beim Original-OAuth mit­ge­hol­fen hatten. Lediglich der leitende OAuth2-Redakteur Eran Hammer-Lahav hatte am alten OAuth mit­ge­ar­bei­tet – und selbst dieser di­stan­zier­te sich schließ­lich von dem neuen Projekt, drei Monate vor der Ver­öf­fent­li­chung. In einem Artikel auf seinem Blog hue­ni­ver­se.com vom 26. Juli 2012 erklärte er die Hin­ter­grün­de für seine Ent­schei­dung und be­zeich­ne­te OAuth 2.0 gleich in der Über­schrift als „Weg in die Hölle“.

Was war passiert? Laut Hammer-Lahav war die Ent­wick­lung des neuen Pro­to­kolls von ständigen Debatten zwischen den Ent­wick­lern und den be­tei­lig­ten Un­ter­neh­men (u.a. Yahoo!, Google, Twitter und auch der Deutschen Bank) bestimmt gewesen. Streit­fra­gen seien meist zugunsten wirt­schaft­li­cher In­ter­es­sen ir­gend­wann ignoriert worden. Kon­se­quenz sei ein Protokoll, das laut Hammer-Lahav nicht mehr als solches be­zeich­net werden dürfte. Denn statt einen eng de­fi­nier­ten Standard dar­zu­stel­len, sei OAuth2 höchstens ein Framework, das man beliebig anpassen und erweitern könne. Damit hätte OAuth2 aber das Merkmal der In­ter­ope­ra­bi­li­tät verloren – un­ter­schied­li­che OAuth2-Im­ple­men­tie­run­gen seien also nicht zwangs­läu­fig mit­ein­an­der kom­pa­ti­bel.

Noch eine Sache bedauert Hammer-Lahav: Dass man sich für eine ein­fa­che­re Im­ple­men­tie­rung ent­schie­den habe (zum Beispiel durch das Weglassen von Si­gna­tu­ren), führe zu einen Mangel an Si­cher­heit. Um eine sichere Anwendung pro­gram­mie­ren zu können, die OAuth2 un­ter­stützt, müssten Ent­wick­ler ein er­heb­li­ches Maß an Expertise mit­brin­gen. Wahr­schein­li­cher sei daher, dass sich künftig schlicht unsichere An­wen­dun­gen im Netz häufen würden. Im­ple­men­tie­rungs­feh­ler seien an­ge­sichts der un­voll­stän­di­gen und übermäßig komplexen Spe­zi­fi­ka­tio­nen un­ver­meid­bar, so Hammer-Lahav.

Mit seinen Be­fürch­tun­gen hatte Hammer-Lahav zumindest teilweise recht: Im Jahr 2016 be­schäf­tig­te sich erstmals eine For­scher­grup­pe von der Uni­ver­si­tät Trier mit der Si­cher­heit von OAuth2 und entdeckte dabei zwei Si­cher­heits­lü­cken. Eine davon er­mög­lich­te Man-in-the-Middle-Attacken. Grund­sätz­lich schätzten die Forscher das Protokoll aber als ver­hält­nis­mä­ßig sicher ein – vor­aus­ge­setzt, es sei korrekt im­ple­men­tiert. Das Team hinter OAuth2 hat die Schwach­stel­len laut eigenen Angaben bereits behoben. Der For­schungs­be­richt war für viele IT-Experten al­ler­dings Anlass, sich in Artikeln näher mit der sicheren Ver­wen­dung von OAuth 2.0 zu befassen.