Was ist eigentlich Open Authentication (OAuth) von dem immer gesprochen wird. Ich versuche es mal möglichst einfach zu erklären:

Angenommen ihr plant Urlaub und könnt eure Katze nicht mitnehmen (OK, wer keine hat, hat bestimmt Pflanzen :D). Also nach drei Wochen würde es der Katze nicht wirklich gut gehen, wenn Sie keiner füttert (oder die Pflanzen gießt). Da ihr das sicher nicht wollt sucht ihr also jemanden eures Vertrauens, dem der Wohnungsschlüssel zeitweilig überlassen wird um die Katze zu füttern und das Streu zu erneuern. Wäre auch echt blöd bei der Rückkehr aus dem Urlaub eine wirklich übel riechende Wohnung vorzufinden.

Abstrahiert heißt das also ihr habt jemanden Autorisiert eure Wohnung zu öffnen und die (erlaubten) Tätigkeiten durchzuführen.

Achtung ihr habt jemanden Autorisiert nicht Authentifiziert, das ist ein großer Unterschied und wird oft verwechselt oder gleichgesetzt. Die Authentifizierung ist für die Prüfung der Echtheit des Schlüssels und der Person zuständig, der ihr den Schlüssel gegeben habt. Angenommen diese Person verliert den Schlüssel oder jemand anderer kopiert ihn, so könnte auch der in die Wohnung. Die Autorisierung würde also vorliegen.

Technisch gesehen behandelt OAuth genau diese Autorisierung, also die Schlüsselübergabe und Verwendung. Es kümmert sich nicht darum, wer der Schlüssel benutzt. Die Echtheit des Schlüssels wird allerdings (bis zu einem gewissen Maß) sichergestellt. Eine genaue Kopie des Schlüssels würde dennoch akzeptiert, wie eben auch an der Wohnungstür.

Sicherheit vs Bequemlichkeit

Den Faden hatte ich schon in der Präsentation für die DNUG aufgenommen und auch auf die IBM Studie verwiesen. Im Prinzip sind diese Anforderungen gegenläufig. Geschäftskritische Anwendungen im Internet, und davon gibt es zunehmend mehr, brauchen Sicherheit. Besonders schwierig wird das bei verteilten Anwendungen, z.B. On Premise und in der Cloud. Dennoch müssen beide Anforderung möglichst weitgehend erfüllt werden, da ansonsten die Gefahr besteht, dass durch Bequemlichkeit (z.B. immer das gleiche Passwort) die Sicherheit auf der Strecke bleibt. Aber darum geht es hier ja nicht, Passworte sind Bestandteil einer Authentifizierung bei der Anmeldung.

OAuth kümmert sich, wie schon beschrieben, nur um die Berechtigung, nicht um die Anmeldung. Die Interaktion mit dem Anwender ist daher nur gering. Allerdings benötigt eine sichere Autorisierung eben auch eine Authentifikation. Diese wiederum muss mit dem Anwender interagieren. Hierzu kommt eine Erweiterung des OAuth Protokolls, das OpenID Connect (OIDC) zum Einsatz. OIDC nutzt OAuth, erweitert es um eine geprüfte Identität und spezifiziert einige Eigenschaften des OAuth genauer, die eigentlich offen sind. Sogenannte Scopes definieren einen bestimmten Umfang an Rechten (z.B. ich darf die Katze füttern oder die Blumen gießen). OAuth beschreibt das es Scopes gibt, lässt dessen Verwendung offen. OIDC beschreibt nun einige Standard Scopes und deren Verwendung. Um eine Authentifizierung (wer ist die Person, der ich den Schlüssel zum Haus gebe?) zu erreichen, bedarf es weiterer Komponenten. Die Person muss sich irgendwie ausweisen. An einem Computer ist der einfachste Fall die Abfrage eines Usernamens und eines Passworts. Man nennt das Authentifizierungsverfahrten. Mit OIDC hat eine Anwendung die Möglichkeit ein solches Verfahren anzufordern bei einem sogenannten Identity Provider. Dieser führt dann die Anmeldung des Users durch und teilt der Anwendung das Ergebnis sowie einige Eigenschaften des Angemeldeten Users mit. Welche das sind, lässt sich von der Anwendung wiederum durch vorherige Übermittelung der erwähnten Scopes definieren.

Opps, war doch etwas kompliziert, darum zurück zur Katze. Gleichzeitig möchte ich einige Begriffe einführen. Ihr (der Ressource Owner) erlaubt also jemand anderem, dem ihr vertraut (dem Client) euer Haus (Ressource Server) zu betreten um die Katze (Ressouce) zu füttern. Dazu benötigt der Client einen Schlüssel (Access Token). Damit der Client nun ein Access Token bekommt, müssen wir noch feststellen, wer den dieser Client ist. Wir vertrauen ja nicht Jedem. Hier kommt der Authorization Server oder IdP (Identity Provider) ins Spiel. Bei dem muss sich der Cleint zunächst ausweisen, bevor er den Schlüssel bekommt und damit bei Ressource Server die Ressource anfragen kann.

Im real Life lässt sich das ganz gut mit Facebook und einer Photoapp erläutern. Facebook hält die Daten des Anwenders und ist Somit IdP. Wenn ich nun von der Photoapp meines iPhones Photos auf Facebook veröffentlichen möchte, muss ich dieser zunächst die Erlaubnis dazu erteilen. Schließlich möchte ich nicht, dass jeder Fotos in meinem Profil postet. Theoretisch könnte ich also das Passwort und die Mailadresse, die zur Anmeldung bei Facebook genutzt werden verwenden. Da ich aber nicht möchte, dass jede App mein Passwort kennt (wer weiß schon wohin die das überträgt), muss die App OAuth nutzen. Facebook stellt dabei den Ressource- und Authorizationserver zur Verfügung. Die App ist der Client.

Drücke ich nun den Veröffentlichen Button, sendet die App einen HTTP Request an Facebook. Darin enthalten sind die benötigten Rechte (Scopes) und einige weitere Informationen, die zur Abwicklung notwendig sind.

Facebook leitet nun weiter an die Login Seite. Hier werden mir die Informationen zum Request der App angezeigt (Appname, angefragte Rechte) und der Anmeldebildschirm von Facebook.

Sofern ich einverstanden bin, kann ich mich anmelden und die Anwendung bekommt einen Schlüssel, mit dem sie nun die Bilder in meinem Facebook Profil veröffentlichen kann.

Die Anwendung kennt also nicht mein Passwort und bekommt nur die Rechte, die ich zulasse. Dummer Weise beantragen viele Apps einfach Zugriff auf meine persönlichen Daten z.B. Namen, Geburtsdatum oder Freunde als mandantory (notwendig) und Facebook gibt mir dann nicht die Möglichkeit diese abzuwählen. In dem Fall bleibt nur die App nicht zu nutzen. Das wäre ja so, als wenn ich dem Katzenfütterer auch erlaube meinen Kühlschrank zu plündern und den Weinkeller zu leeren.

Zusammengefasst verhindert OAuth also das mein Passwort bei einer nicht vertrauenswürdigen Instanz landet. Ob Facebook vertrauenswürdig ist, darüber lässt sich streiten. Wenn ich dort aber einen Zugang angelegt habe, möchte ich vermeiden, dass meine Anmeldedaten auch anderen zur Verfügung stehen. Sicher ist jeder schon einmal mit OAuth in Berührung gekommen. Hier ein Beispiel von Zoom:

Ich hoffe das hat das Thema OAuth etwas verdeutlichet. Wir implementieren gerade einen IdP mit vielen weit über Facebook hinausgehenden Features, für einen großen Automotive OEM. Falls der Artikel also das Interesse geweckt hat kommt gerne auf mich zu. Die Anwendungsmöglichkeiten sind vielfältig und es geht nicht nur um Sicherheit, auch um Bequemlichkeit . Dazu mehr in weiteren Artikeln.