OAuth 2.0 Autorisierung einfach erklärt. So macht es google und Co!

Keylearnings:

  • Wie funktioniert OAuth 2.0?
  • Was ist Autorisierung?
  • Was ist das Passwort Antipattern?
  • Welche Akteure sind im OAuth 2.0 Verfahren beteiligt?
  • Wie spielen die Akteure im OAuth Protokoll zusammen?

Meine Mutter war im Urlaub. Anderthalb Wochen auf Langeoog an der Nordsee.

Aber sie hatte ein Problem!

Ihre Zimmerpflanzen. Keine Kakteen sondern Bonsai, Narzissen und Orchideen.

Blumen für den grünen Daumen, um die man sich kümmern muss!

Überlebenschance nach anderthalb Wochen ohne Pflege unter NULL!

Sie brauchte Hilfe!

Jemanden, der die Pflanzen während ihrer Abwesenheit mit Wasser versorgt.

Jemanden, dem Sie vertraut, jemandem dem sie sorglos den Wohnungsschlüssel übergeben kann.

Eine X beliebige Person kam also nicht in Frage.

Es musste eine Person sein, die das Vertrauen meiner Mutter genießt.

Eine Person, bei der sie sich darauf verlassen konnte, dass diese den anvertrauten Wohnungsschlüssel nicht dazu benutzt den Kühlschrank zu plündern, sondern nur dafür um die Wohnungstür aufzumachen um die Blumen gießen zu können.

Diese verantwortungsvolle Aufgabe (ich sage das mit vollem ernst!) hat meine Mutter mir übertragen.

Yeah! Meine Mum vertraut mir. 🙂

OAuth 2.0

Den Vorgang jemanden für etwas zu berechtigen nennt der Fachmann Autorisierung, das wir aber auf keinen Fall mit dem  ähnlich klingenden Wort Authentifizierung verwechseln dürfen.

Der Unterschied zwischen Autorisierung und Authentifizierung

Sollte ich überfallen werden und ein Dieb mir den Schlüssel entwenden, so kann sich dieser ebenfalls Zugang zur Wohnung meiner Mutter verschaffen und den Kühlschrank plündern. Genauso besteht die Möglichkeit, dass eine Kopie des Schlüssels existiert.

Die Echtheit des Schlüssels und der Identitäts-Nachweis meiner Person ist Aufgabe der Authentifizierung und nicht der Autorisierung.

Vom technischen Standpunkt aus gesehen, hat mich meine Mutter also dazu autorisiert die Wohnung zu öffnen um die Blumen zu pflegen.

Und Autorisierung ist genau das Thema, um das es in diesem Artikel gehen soll.

Hierfür werden wir uns das OAuth 2.0 (Open Authorization) Protokoll ansehen. Dieses Protokoll wird unter anderem bei den von Google angebotenen Diensten wie gmail oder dem Cloud Storage Google drive zur Autorisierung verwendet.

Hast du schon mal sowas gesehen?

OAuth 2.0

Ja? Sehr gut, dann bist du bereits mit OAuth in Kontakt gekommen.

Vertrauen braucht das Internet.

Immer mehr sogenannter geschäftskritischer Prozesse werden über das Internet abgewickelt wodurch die Wichtigkeit einer leistungsfähigen Autorisierungs-Möglichkeit auf der Hand liegt.

Hierbei bedeutet leistungsstark, dass die Autorisierung sicher und bequem sein soll. Diese beiden Faktoren verhalten sich gegenläufig.

Die besondere Schwierigkeit hierbei ist, dass die Anwendungen im Internet zunehmend verteilt werden.

So kannst du beispielsweise deine Bilder, die du mit der Foto-App deines Handys erstellst unmittelbar auf Facebook posten und das obwohl deine Foto-App nicht zum Facebook-Portfolio gehört.

Wie funktioniert das?

Facebook stellt hierfür eine von außen sichtbare (öffentliche) API (Application Programming Interface) bereit, die als RESTful Webservices implementiert ist.

Mit Hilfe dieser API können wir Programme schreiben, welche die üblichen Facebook Funktionen wie Post’s erstellen, Likes vergeben oder Freundesanfragen verschicken, ausführen können.

Aber haben wir soviel vertrauen, dass wir unserer Foto App erlauben wollen alle diese Funktionen zu verwenden?

Nein, das wäre eine Sicherheitslücke! Vertrauen ist gut, aber Kontrolle ist in diesem Fall noch besser.

Womit wir wieder bei dem Problem der Autorisierung sind. Wir wollen unserer Foto-App zwar erlauben Bilder zu posten aber verbieten Freundschaftsanfragen zu verschicken.

Welche Möglichkeiten haben wir das zu realisieren?

Eine Möglichkeit wäre es, bei jedem API Aufruf eine Erlaubnis vom Anwender anzufordern, die er mit seinen Facebook Anmeldedaten bestätigen muss.

Wir müssten also vor jedem Bild, das wir posten wollen unsere Anmeldedaten eingeben. Sehr nervig und keine gute User Erfahrung. Das würde der 19 jährigen Touristin aus Rom mit Selfie-Stick-Implantat mit Sicherheit nicht gefallen.

Natürlich könnte unsere App die Anmeldedaten speichern, sodass diese nicht jedes mal erneut eingegeben werden müssen. Das wäre aber ungefähr so, als würden wir unsere Wohnungsschlüssel einer x beliebigen Person anvertrauen.

Dieses Vorgehen hat also einen entscheidenden Nachteil, deshalb sprechen wir bei dieser Vorgehensweise auch von einem Antipattern. Dem sogenannten Passwort Antipattern.

Wir benötigen also eine andere Lösung und die liefert uns das OAuth Protokoll.

Das OAuth 2.0 Protokoll in Aktion!

Bleiben wir bei unserem Beispiel mit der Foto-App, in der wir Bilder direkt auf unsere Facebook-Timeline posten wollen. In diesem Szenario haben wir folgende Akteure.

Zum einen den Anwender, den wir Tim nennen wollen.

Tim hat einen Facebook Account mit sogenannten Ressourcen, die aus Tims Bildern, seiner Freundesliste und den Postings auf seiner Timeline bestehen.

Da sich diese Ressourcen eindeutig Tim zuordnen lassen, nennen wir Tim auch den Ressource-Owner.

Verwaltet werden diese Ressourcen durch einen Ressourcen-Server, der auch für den sicheren Zugriff auf die Ressourcen verantwortlich ist.

Möchte Tim ein Post auf seiner Timeline hinzufügen, muss er sich zunächst auf dem Ressourcen-Server einloggen. Dies kann beispielsweise durch die Eingabe eines Passworts geschehen.

Willkommen liebes Passwort Anitipattern. Wir wollen dich nicht! 😉

Als letzten und kritischsten Akteur haben wir noch unsere Drittanbieter Foto-App, die Bilder direkt auf Tims Timeline posten möchte.

Wie können wir die Übertragung des Passworts von der Foto-App zum Ressourcen-Server vermeiden?

Um das Problem des Passwort Antipattern mit Hilfe von OAuth zu lösen, führen wir einen weiteren Akteur ein und zwar den sogenannten OAuth Server.

Mit Hilfe dieses zusätzlichen Servers können wir vermeiden, dass sich unsere Foto-App mit dem Passwort beim Ressourcen-Server anmelden muss.

Und das ganze funktioniert wie folgt.

So funktioniert OAuth 2.0 im Groben!

Anstatt den Ressource-Server direkt zu kontaktieren setzt sich unsere Foto-App zunächst mit dem OAuth Server in Verbindung und fordert bei diesem die Rechte an um in Tims Timeline ein Foto posten zu dürfen.

Anschließend wendet sich der OAuth Server an den Ressource Owner Tim, wodurch bei diesem ein Login-Dialog erscheint, in welchem er sich mit seinen Faceboook-Anmeldedaten einloggt. Hiermit erklärt Tim sein Einverständnis dafür, dass die Foto-App ein Bild auf seiner Timeline posten darf.

Sobald Tim die Anmeldedaten eingegeben hat, werden diese an den OAuth Server geschickt, der das Passwort validiert und im Erfolgsfall Tim als Ressource-Owner authentifiziert.

Im nächsten Schritt erstellt der OAuth Server ein sogenanntes Token, das an unsere Foto-App gesendet und in der Datenbank auf dem OAuthServer gespeichert wird. Das Token beinhaltet die entsprechenden Autorisierungs-Informationen.

Hinweis:  Das OAuth Protokoll kann in vier unterschiedlichen sogenannten Grant Types implementiert werden. In unserem Beispiel beschreiben wir den Grant Type Implicit Grant, bei welchem der Auhorization Server direkt ein Token ausstellt. Bei anderen Grant Types wie beispielsweise dem Authorization Grant Type wird das Token nicht direkt ausgestellt sondern es wird zunächst ein Authorization-Code erzeugt.

Jedes Token hat eine endliche Lebensdauer nach deren Ablauf es seine Gültigkeit verliert.

Das Token ist sowohl dem OAuth Server als auch unserer Foto-App bekannt.

Zusammen mit dem Token fragt unsere Foto-App beim Ressource-Server um die Erlaubnis ein Bild auf Tims Timeline posten zu dürfen.

Der Ressource Server muss jetzt nur noch die Gültigkeit des Tokens feststellen. Zu diesem Zweck fragt er beim OAuth Server nach, ob dieser das Token in seiner Datenbank finden kann und ob es noch gültig ist.

Ist das der Fall, wird das zu postene Bild Tim’s Ressource hinzugefügt.

Bekanntlich sagt ein Bild mehr als 1000 Worte, daher hier eine bildliche Darstellung des OAuth Workflows.

OAuth Workflow im Groben

Entscheidend hierbei ist, dass die Drittanbieter-App niemals mit Tim’s Einlog-Daten in Berührung kommt.

Warnung: Das Token besitzt keine Authentifizierungsmerkmale. Jeder, der in den Besitz des Tokens kommt, kann im Rahmen der gewährten Autorisierung auf Tims Ressource zugreifen. Daher ist es dringend erforderlich, dass der Austausch des Tokens zwischen App und Ressourcen-Server bzw. zwischen Ressourcen und OAuth-Server auf sicherem Weg erfolgt

Der OAuth Flow im Detail

Nachdem wir uns im vorhergehenden Abschnitt einen groben Überblick über die Funktionsweise von OAuth verschafft haben, wollen wir uns nun die Komponenten im Detail ansehen.

Das OAuth Protokoll sieht unterschiedliche Workflows vor. Bei unserer Betrachtung beschränken wir uns auf die sicherste Variante und zwar dem sogenannten Authorization Code Flow. Alle weiteren OAuth Flows sind Vereinfachungen des Authorization Code Flow.

Dieser Flow erfordert allerdings beispielsweise die Möglichkeit, dass wir ein sogenanntes Client Secret speichern können. Da das nicht immer sicher möglich ist, besteht die Notwendigkeit, auf zwar schwächere dafür aber Flows mit geringeren Anforderungen ausweichen zu können.

Beginnen wir also damit uns die einzelnen Teilnehmer im OAuth Workflow im Detail anzusehen um anschließend deren Zusammenspiel verstehen zu können.

Den Ressource Owner

Der Ressource Owner ist der Eigentümer, der Ressourcen, die wir vor unautorisierten Zugriffen durch dritte schützen wollen. Falls du einen Facebook Account besitzt, bist du beispielsweise der Ressource Owner deiner Postings, deiner Bilder, und deiner Freundesliste.

Mit Sicherheit möchtest du nicht, dass irgendein daher gelaufener Wilder in deinem Namen Mobbing betreibt. Und genau deshalb dürfen die Zugriffe auf diese Ressourcen nur autorisiert erfolgen.

Des Weiteren ist der Ressource Owner der Teilnehmer, der im besitz der Authentifizierungs-Informationen, den sogenannten Credentials ist. Im Falle deines Facebook-Accounts bestehen die Credentials aus deiner Email-Adresse und deinem Passwort.

Den Client

Der zweite Teilnehmer ist der Client, welcher auf die Ressourcen des Ressourcen Owners zugreifen möchte. Häufig ist der Client der Teilnehmer, dem wir aus Sicherheitsgründen nicht blind vertrauen sollten, da es sich hierbei oft um einen Drittanbieter handelt.

In unserem Beispiel ist der Client die mobile Fotoapp, mit der Tim seine Urlaubsbilder direkt auf seiner Facebook-Timeline veröffentlichen kann.

Der OAuth Server

Mit Hilfe des OAuth Servers können wir die Probleme des Passwort Antipattern beheben. Der OAuth Server ist dafür verantwortlich dem Client ein Token auszustellen, mit dem dieser die Berechtigungen erhält die gewünschten Aktionen auf den Ressourcen des Ressource Owners auszuführen. Und zwar NUR diese!

Für diesen Zweck stellt der OAuth Server in der stärksten Variante (Authorization Grant) zwei REST Webservice Endpunkte zur Verfügung. Einen zum Zweck der Autorisierung und einen weiteren, über den das Autorisierungs-Token für den Client erstellt wird.

Der Ressource Server

Der letzte Teilnehmer im OAuth Workflow ist der Ressource Server, auf dem die Ressourcen des Ressource Owners gespeichert sind, auf die der Client über eine geschützte API zugreifen kann.

Zugriff auf die API erhalten nur die Teilnehmer, welche entweder ein gültiges Zugriffstoken oder gültige Credentials besitzen.

In unserem Beispiel wird der Ressource Server von Facebook zur Verfügung gestellt.

Nachdem wir uns alle Teilnehmer im OAuth Workflow detailliert angesehen haben, wollen wir nun das Zusammenwirken aller Mitstreiter am Beispiel des OAuth Authorization Code Grant kennen lernen.

Der OAuth Authorization Grant Type.

Beim Authorization Code Grant besteht der Workflow aus drei Bestandteilen.

1. Erzeugung des Autorisierungs-Code.

Tim ist in Rom und hat ein Foto des Colosseums gemacht, das er mit Hilfe seiner Drittanbieter Foto-App sofort auf seiner Facebook Timeline veröffentlichen möchte.

OAuth 2.0 Bild

Die Foto-App ist zusammen mit einem Client-Secret am OAuth-Server registriert.

Nachdem Tim auf seiner App den veröffentlichen Knopf gedrück hat, wird ein http GET Request an den OAuth-Server gesendet. Hierbei enthält der http Request Informationen über die benötigten Autorisierungs-Rechte, eine client-Id zur Identifikation der App und eine URL, an welche der Autorisierungs-Code zurück gesendet werden soll.

Anschließend wird Tim zum Facebook Login weitergeleitet.

Sobald Tim hier seine Login Daten korrekt eingegeben hat, wird Tim sicherheitshalber erneut darüber aufgeklärt was die Foto-App vor hat und um Zustimmung gebeten.

Sobald er die Erlaubnis erteilt hat, steht der Weg frei ein Autorisierungs-Token zu erzeugen. Die Arbeit des Authorisierungs-Endpunkt des OAuth Servers ist damit bereits abgeschlossen.

Zur Verdeutlichung im folgenden eine Skizze, die den Workflow visualisiert.

OAuth Autorisierungs-Code

Jetzt muss der Token-Endpunkt die Arbeit aufnehmen. Übrigens ist dir aufgefallen, dass wir den Ressource-Server bis jetzt noch garnicht benutzt haben?

2. Erzeugung des Autorisierungs-Token

Nachdem der erste Schritt ausgeführt wurde sind wir jetzt im besitzt eines kurzlebenden Autorisierungs-Code. Diesen senden wir mit Hilfe eines http POST Request an den Token-Endpunkt des OAuth Servers. Hierbei setzt sich der Autorisierungs-Code aus der Client-Id und einem Client-Secret zusammen. Außerdem wird der Autorisierungs-Code Base64 codiert.

Der Autorisierungs-Code wird vom OAuth Server validiert. Im Falle eines positiven Validierungsergebnis wird ein JSON Objekt an den Client zurück geliefert.

Neben dem eigentlichen Token enthält dieses Objekt noch die Lebenszeit des Tokens in Millisekunden und ein Refresh-Token, mit dem nach Ablauf des ursprünglichen Tokens ein neues Autorisierungs-Token vom OAuth Server geordert werden kann, und zwar ohne dass ein neuer Autorisierungs-Code erzeugt werden muss.

Auch hier kann der Vorgang wieder durch eine Skizze verdeutlicht werden.

OAuth 2.0 Step 2

 

In diesem Schritt ist weder der Ressource Server noch der Ressource Owner involviert.

3. Zugriff auf die gewünschte Ressource mit Hilfe des Autorisierungs-Token

Noch immer hat kein Zugriff auf den Ressourcen-Server stattgefunden.

Allerdings haben wir jetzt ein gültiges Autorisierungs-Token, mit dem wir auf die API des Ressource-Servers zugreifen können und hiermit das Bild des Kolosseums auf Tims Timeline posten dürfen.

Leider ist die API des Ressource-Servers nicht in der Lage die Gültigkeit des Tokens festzustellen. Daher muss das Token vom Ressource-Server an den OAuth Server weitergeleitet werden, der eine entsprechende Prüfung des Tokens durchführt.

Ist das Token vom OAuth Server als valide eingestuft worden, wird das dem Ressourcen-Server mitgeteilt, der daraufhin die API Methode, mit der das Kolosseum auf Tim Timeline gepostet werden kann frei gibt. Andernfalls wird dem Client die Verwendung der Ressource-Server API verwehrt.

Die Bestandteile dieses Schritts können ebenfalls in einer Skizze dargestellt werden.

In diesem Teil des OAuth Workflows bleibt der Ressource-Owner außen vor.

OAuth Schritt 3

Fazit: In diesem Artikel haben wir uns einen Überblick über das OAuth 2.0 Protokoll verschafft. Sinn und Zweck des OAuth Protokolls ist es die Sicherheitsprobleme, die bei verteilten Systemen insbesondere dann entstehen, sobald Software von Drittanbietern ins Spiel kommt zu lösen.

Das OAuth Protokoll ermöglicht es uns die Probleme des Passwort Antipattern zu vermeiden indem wir es, durch die Einführung eines OAuth Servers, der Zugriffstokens mit begrenzter Lebensdauer ausstellt, vermeiden sicherheitssensible Daten wie Passwörter einer Software eines Fremdanbieters bekanntzugeben.

Im Artikel haben wir uns lediglich zwei Ausprägungen von OAuth 2.0 angesehen. Zum einen den Implicit Grant Type, der insbesondere bei JavaScript Webanwendungen eine Rolle spielt, und zum anderen den stärksten Grant nämlich den Authorization Grant. Darüber hinaus gibt es noch den Passwort und den Client Grant. Diese sind zwar weniger komplex dafür aber auch weniger sicher und lösen die Problematik des Passwort Anti-Pattern nur unzureichend.

Ich freue mich auf deine Fragen im Kommentarbereich!

Hat dir der Artikel gefallen? Dann folge uns doch gleich auf Facebook!

Hallo ich bin Kim und ich möchte ein großer Programmierer werden. Machst du mit?

Kommentare (6)

  • Antworte

    tolle Erklärung. auch für einen Laien sehr verständlich!

    • Vielen Dank für das Feedback. LG Kim

  • Antworte

    Klasse erklär, gut dargestellt ;D

    • Hi Max, danke dir!

  • Antworte

    Danke für die gute Erklärung! Frage: Wer betreibt den OAuth-Server?

    • Hallo Cooney, in dem Beispiel im Artikel werden die meisten Komponenten von Facebook betriben. Es ist aber möglich, dass jede Komponente im OAuth Flow von einem eigenen Anbieter (Provider) betrieben wird. Viele Grüße Kim

Hinterlasse ein Kommentar