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

Angenommen Sie planen einen Urlaub und können Ihre Katze nicht mitnehmen (Sie haben gar keine Katze? Das macht nichts, denn dann haben Sie sicher zumindest Pflanzen in Ihrer Wohnung). Wir sind uns sicher einig darüber, dass es der Katze nach drei Wochen ohne Futter nicht wirklich gut gehen würde und Ihre Pflanzen ganz bestimmt das Zeitliche gesegnet hätten, wenn sie niemand gegossen hätte. Da das sicher nicht in Ihrem Sinne ist, suchen Sie sich also jemanden Ihres Vertrauens, dem Sie den Wohnungsschlüssel zeitweilig überlassen um die Katze zu füttern.

Abstrahiert heißt das also Sie haben jemanden autorisiert Ihre Wohnung zu öffnen und die (erlaubten) Tätigkeiten durchzuführen.

Achtung! Sie haben 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 Sie den Schlüssel gegeben haben. Angenommen diese Person verliert den Wohnungsschlüssel oder jemand anders kopiert ihn, so dass auch er in die Wohnung gelangen könnte. 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 den 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 

Im Prinzip sind diese Anforderungen gegenläufig. Geschäftskritische Anwendungen im Internet, und davon gibt es zunehmend mehr,brauchen Sicherheit. Besonders schwierig wird dies bei verteilten Anwendungen, z.B. On Premise und in der Cloud. Dennoch müssen beide Anforderungen möglichst weitgehend erfüllt werden, da ansonsten die Gefahr besteht, dass durch Bequemlichkeit (wenn man z.B. immer das gleiche Passwort verwendet) 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, sogenannten Claims (z.B. ich darf die Katze füttern oder die Blumen gießen). OAuth beschreibt, dass 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 Authentifizierungsverfahren. Mit OIDC hat eine Anwendung die Möglichkeit ein solches Verfahren bei einem sogenannten Identity Provider anzufordern. 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 Übermittlung der erwähnten Scopes definieren.

Ooops, war doch etwas kompliziert, darum zurück zur Katze, aber lassen Sie mich erst noch einige Begriffe einführen: Sie (der Ressource Owner) erlauben also jemand anderem, dem Sie vertrauen (dem Client) ihr Haus (Ressource Server) zu betreten, um die Katze (Ressource) 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 Client zunächst ausweisen, bevor er den Schlüssel bekommt und damit bei dem Ressource Server die Ressource anfragen kann.

Im realen Leben lässt sich das ganz gut mit Facebook und einer Foto-App erläutern. Facebook hält die Daten des Anwenders und ist somit IdP. Wenn ich nun von der Foto-App meines iPhones Fotos 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 das übertragen wird), 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. Dummerweise 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, dass 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.

Beispiel von Zoom

oauth

Ich hoffe das hat das Thema OAuth etwas verdeutlicht.

Die TIMETOACT GROUP implementiert gerade für einen großen Automotive OEM einen IdP mit vielen Features, die weit über Facebook hinausgehen.

Falls dieser Artikel Ihr Interesse geweckt hat, kommen Sie gerne auf mich zu.

Die Anwendungsmöglichkeiten sind vielfältig und es geht nicht nur um Sicherheit, auch um Bequemlichkeit!