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. 🙂
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?
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.
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.
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.
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.
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.
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!
Mark G.
14. Mai 2018 at 21:40tolle Erklärung. auch für einen Laien sehr verständlich!
Kim Peter
15. Mai 2018 at 6:00Vielen Dank für das Feedback. LG Kim
Max E.
29. August 2018 at 10:59Klasse erklär, gut dargestellt ;D
Kim Peter
8. September 2018 at 19:31Hi Max, danke dir!
Cooney
16. Oktober 2018 at 12:32Danke für die gute Erklärung! Frage: Wer betreibt den OAuth-Server?
Kim Peter
27. Oktober 2018 at 15:42Hallo 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
Sascha (Ex-mps)
19. Dezember 2018 at 9:17Hi Kim,
war gerade im Netz unterwegs auf der Suche nach einer Erläuterung des OAuth Protokoll und bin hier bei dir gelandet. Tolle Erklärung.
Viele Grüße
Kim Peter
19. Dezember 2018 at 12:19Hallo Sascha, freue mich sehr von dir zu hören. Hoffe bei dir ist alles gut. Freue mich wenn dir mein geschreibsel weitergeholfen hat.Schöne Grüße aus Rösrath
Jean
6. Januar 2019 at 18:58Hallo Kim,
tipp, topp, super verständlich erklärt!
Hat mir sehr weiter geholfen!
Beste Grüsse
Kim Peter
6. Januar 2019 at 19:03Hallo Jean,
super! Ich danke dir!
Viele Grüße Kim
Eva M.
2. Februar 2019 at 9:24Hallo Kim!
Habe ewig nach einer verständlichen Erklärung gesucht und endlich eine gefunden
Danke Dir – super verständlich und nachvollziehbar! 🙂
Kim Peter
3. Februar 2019 at 10:22Hallo Eva, vielen Dank für dein Feedback! Viele Grüße Kim
Ashka
21. Februar 2019 at 9:38Vielen lieben Dank für so eine tolle Erklärung!
Kim Peter
21. Februar 2019 at 9:41Sehr gerne!
christian
12. März 2019 at 7:50Sehr cool erklärt Kim!
Ich mache sowas ja beruflich, muss das aber oft Laien oder Anwendern erklären – so versteht das wirklich jeder.
Kim Peter
13. März 2019 at 7:38Hallo Christian, vielen Dank für dein Feedback! Viele Grüße Kim
Deploy Ment
9. Mai 2019 at 11:54Hi Kim,
als angehender Fachinformatiker muss ich mich mit dem Thema OAuth 2.0 auseinandersetzen. Mit dieser verständlichen Erklärung fällt mir der Einstieg wesentlich leichter.
Vielen Danke!
🙂
Kim Peter
2. Juli 2019 at 11:31Super das freut mich!
Henrik
17. Juni 2019 at 12:28Hi Kim, tolle Erklärung! Wie siehst Du Provider in diesem Kontext, die den OAuth-Server für DIch betreiben können? Z.B.: Azure AD?
VG
Kim Peter
2. Juli 2019 at 11:18Hallo Henrik, halte ich für sinnvoll. Man muss ja nicht alles neuerfinden. Viele Grüße Kim
Froschkoenig84
20. August 2019 at 10:39Hallo Kim,
ich bin .NET Core (C#) Anfänger und versuche mich nach einigen Jahren PHP ein wenig mehr zu professionalisieren.
Als erstes Test-Projekt dachte ich an ein Portal, dass Restaurants und Bars die Möglichkeit bietet, deren gesamten Infos (Ort, Öffnungszeiten/Sommerpausen, aktuelle Events, Speisekarten, Kosten, Awards, etc…) zu publizieren. Quasi einen Mix aus Facebook, den GelbenSeiten und TripAdviser. Allerdings mit einigen Optionen mehr, die mehr einer Community ähneln. Daher benötige ich eine vernünftige, stabile, sichere und zugleich einfache Authentifizierung.
Hierbei kam mir OAUTH-2.0 in den Sinn und dank deiner kleinen Einführung wurde mein Interesse geweckt. Ich werde nun versuchen mich tiefer in die Thematik einzuarbeiten. Was ich leider noch gar nicht verstanden habe, sind die Kosten dieser Technologie. – Also OAUTH kann ja nicht kostenfrei funktionieren. Irgendwo muss ja meine USR:PWD-AUTH aufbewahrt werden und das macht ja niemand umsonst. Beispielsweise bietet OKTA bereits relativ günstige Plans an, auch wenn ich mir hier noch nicht ganz über die Skalierung im Klaren bin.
Hast du hier einige Infos? Denn gerade wenn man nur Dinge ausprobieren (Lernprojekte) oder ein kleines StartUp (Prototyp-Projekt) gründen möchte, sieht man sich gezwungen, jeden Cent mehrmals umzudrehen. – Hier wäre ich dir wirklich dankbar für weitere Tipps und Infos.
Kim Peter
20. August 2019 at 10:55Hallo Froschkönig, da du dich mit .NET für Microsoft entschieden hast, glaube ich dass die das Identity Management von Microsoft Azure ganz gut zu sagen würde. Wäre insbesondere dann sinnvoll, falls du auch den Rest deiner Software in der Azure Cloud betreiben möchtest. Eine alternative wäre keycloak. Natürlich kann man sich ein Identity Management System auch selber bauen. Hier zahlst du allerdings die Kosten in Form von sehr sehr vielen Stunden arbeit. Ich hoffe das hlift. Viele Grüße Kim
Froschkoenig84
20. August 2019 at 13:54Super, Danke!
Eva Vogel
28. Februar 2020 at 7:38Super danke! Office schafft grade den OAuth 2.0 für Exchange online ab und deshalb war Dein Artikel sehr erhellend! Durch die schrittweise Übertragung von Exchange Aufgaben und Azure und andere Server können viele MCSEs sich schon mal emotional auf die nächste Zertifizierung einstellen. 😎 Freundliche Grüße von Eva Vogel (MCP)
Kim Peter
19. Mai 2020 at 18:32Danke Eva!
Choose a style: