Autorisierung und Authentifizierungsmöglichkeiten im Web

In dem heutigen Blog-Eintrag gehen wir auf die Autorisierungslösung OAuth ein und versuchen Ihnen die Funktionsweise verständlich näher zu bringen. Zudem werden wir Ihnen OpenID als Alternative, sowie seine Unterschiede zu dem OAuth-Protokoll, näher bringen.

OAuth selbst ist ein offenes Protokoll, welches eine standardisierte und sichere REST (Representational State Transfer) / API Autorisierung für Desktop-, Web-, Mobile-Anwendungen, aber auch für Konsolen und TV-Geräte ermöglicht.

Eine API (engl. application programming interface) ist eine Programmierschnittstelle, mithilfe dieser können Entwickler auf bestimmte Funktionen einer Anwendung zugreifen.

Die Entwicklung von OAuth startete Ende November im Jahre 2006 und war ein Zusammenschluss von Flickrs-API-Auth- und Googles AuthSub-Verfahren zur Authentifizierung. Ende 2007 wurde bereits der erste Entwurf veröffentlicht.
Diese Autorisierungstechnik ist Ihnen bestimmt auch schon das ein oder andere mal über den Weg gelaufen. Bei vielen Webseiten sieht man immer wieder Buttons mit der Aufschrift „Login via Twitter“ oder „Login via Google“. All diese Dienste nutzen OAuth, um es dem Nutzer zu ersparen, sich für jeden Dienst separat registrieren zu müssen.
Im Beispiel Twitter, registriert sich der Nutzer Max Mustermann einmalig bei Twitter. Von nun an kann er sich bei allen Diensten, die den Login via Twitter anbieten, registrieren ohne, dass er diesen Diensten seine Zugangsdaten anvertrauen muss.

Mittels OAuth wird Authentifizierung und Autorisierung voneinander entkoppelt.

Lediglich bestimmte Benutzerinformationen, sogenannte Scopes, werden übergeben.
Natürlich gibt es auch hier schwarze Schafe, die versuchen die größtmögliche Berechtigung auf den Account zu erhalten. Die von dem Dienst verlangten Daten werden jedoch im Registrierungsprozess dem Nutzer dargestellt, sodass dieser, diese bearbeiten kann.

Amazon, Google und Twitter haben diese Technik bereits standardisiert, wobei die letzten beiden Firmen aktiv an der Entwicklung beteiligt waren.
Im Oktober 2012 erschien mit OAuth2 eine aktualisierte Fassung der Autorisierungslösung, welche jedoch nicht weiter abwärtskompatibel zu seinem Vorgänger war. OAuth2 beinhaltet insgesamt vier unterschiedliche Rollen für den Benutzer sowie der Anwendung. Diese Rollen sind:

• Resource-Owner: In den meisten Fällen ist dies der Besitzer der Daten, sprich der Benutzer
• Resource-Server: Auf diesem Datenserver liegen die Daten der Benutzer
• Client: Eine Third-Party Anwendung, die auf die geschützten Daten des Resource Owners zugreifen möchte
• Authorization-Server: Aufgrund der hinterlegten Berechtigungen entscheidet dieser, ob die Client Anwendung Zugang zu den Daten des Benutzers erhält und stellt anschließend einen zeitlich begrenzten Token aus.

Ressource- und Authorization-Server werden in der Regel meist zusammen betrieben und bilden somit den OAuth-Server.

Abstrakter Protokollfluss
In folgender Skizzierung wird veranschaulicht wie sich ein Client über den Resource Owner, zum Authorization Server, bis hin zum Resource Server verifiziert.

A → Der Client beantragt die Genehmigung vom Resource-Owner
B → Der Client erhält eine Genehmigung
C → Der Client fragt einen Access Token vom Authorization-Server an. Hier übermittelt er den Authorization Grant
D → Der Authorization-Server authentifiziert den Client und überprüft die Authorization Anfrage. Wenn diese valid ist, erstellt der Authorization-Server einen Access Token
E → Der Client fragt die geschützten Informationen von dem Resource-Server ab und authentifiziert sich mit dem Access Token
F → Der Resource Server validiert den Access Token, wenn dieser valid ist, verarbeitet der Server den Request

Abstrakter Protokollfluss mit abgelaufenen Access Token
In folgender Skizzierung wird veranschaulicht wie sich ein Client mithilfe von Access Token, bzw. abgelaufenen Access Token über den Authorization-Server verifizieren.

A → Der Client beantragt einen Access Token, indem er sich am Authorization Server authentifiziert
B → Der Authorization Server authentifiziert den Client und validiert die Authorisationsanfrage. Wenn diese valid ist, wird ein Access und Refresh Token ausgestellt
C → Der Client fragt die geschützten Informationen mittels des Access Tokens an
D → Der Resource Server validiert den Access Token und verabeitet den Request, wenn der Token valid ist
E → Schritte C und D wiederholen sich solange, bis der Access Token abgelaufen ist.
Wenn der Client weiß, dass der Token abgelaufen ist, springt er zu G, ansonsten versucht er Schritt D erneut
F → Solange der Access Token invalid ist, antwortet der Resource Server mit einem Fehler
G → Der Client fragt einen neuen Access Token, indem er dem Authorization Server, den Refresh Token übergibt.
H → Der Authorization Server autentifiziert den Client und validiert den Refresh Token. Ist dieser valid, wird ein neuer Access Token erstellt und optional auch ein neuer Refresh Token.

OpenID
2005 wurde das Protokoll von Brad Fritzpatrick, dem Gründer des LiveJournals entwickelt. Im Juni 2007 wurde die OpenID Foundation, in den USA, gegründet, die sich die Verwaltung von Urheber- und Markenrechten, sowie das Marketing zur Aufgabe gemacht hat. Zur gleichen Zeit entstand in Belgien die OpenID Europe Foundation, die die gleichen Vorhaben hat, jedoch für den europäischen Raum zuständig ist.
OpenID Connect ist ein weiteres Protokoll, welches eine Schicht oberhalb des OAuth-Protokolls liegt. Am 26. Februar 2014 wurde durch die OpenID Foundation, OpenID Connect als neuer Standard verabschiedet(https://www.heise.de/developer/meldung/OpenID-Connect-als-Standard-ratifiziert-2126073.html).

OpenID Connect hat viele Ähnlichkeiten zu OpenID 2.0, beide Protokolle lösen in der Tat ähnliche Probleme, doch OpenID nutzt XML und ein benutzerdefiniertes Nachrichten-Signaturen-Schema, welches sich für Entwickler in der Praxis manchmal als schwierig herausstellte. Dies hatte zur Folge, dass OpenID 2.0 Implementierungen manchmal die Interoperabilität auf nicht geklärte Art und Weise ablehnte.
OpenID Connect verwendet die Standard-JSON-Web-Token-Datenstrukturen (JWT), sobald Signaturen erforderlich sind.
Dadurch wird die Implementierung für Entwickler erheblich vereinfacht. In der Praxis hat sich mit OpenID Connect die Interoperabilität erheblich verbessert. – Diese wurde, von Mitgliedern der OpenID Connect Arbeitsgruppe und den Entwicklern von zahlreichen OpenID Connect-Implementierungen, bewiesen.

Mit dem neuen Protokoll ist es möglich, die Identität eines Anwenders mithilfe eines Autorisierungsservers zu validieren, sowie zudem Profilinformationen zu erhalten.
Das Protokoll ist bereits von großen Unternehmen wie Amazon, Deutsche Telekom, Google, IBM, Microsoft, salesforce.com, VMware und diversen anderen integriert.

Fazit
OAuth2 ermöglicht eine delegierte Autorisierung und prüft, ob es einen berechtigten Zugriff auf Ressourcen gibt, ohne dass die Third-Party Applikation keinen Zugriff auf Anmeldedaten des Benutzers erhält. Zudem kann der Benutzer zu jeder Zeit jenen Zugriff über den Autorisierungsservice widerrufen.
Der größte Vorteil ist jedoch, dass der Benutzer nur ein Benutzerkonto benötigt und sich mit diesem bei allen OAuth2 kompatiblen Diensten registrieren bzw. anmelden kann, wenngleich dieser Autorisierungsprozess eher ein Nebenprodukt ist.

OpenID Connect bietet im Großen und Ganzen die gleichen Hauptfunktionen, wie OAuth2, da es auf diesem Protokoll aufbaut, dennoch wurden ein paar extra Interaktionen hinzugefügt.
OpenID Connect bietet einer Anwendung, Informationen über den authentifizierten Benutzer abzurufen. Die wichtigste Eigenschaft ist jedoch, die Gewährleistung der Gültigkeit der Informationen.

In der Vergangenheit wurde eine Föderation mit OAuth2 erreicht, indem ein Bereich gewährt wurde, die den Zugriff auf die Identitätsinformationen des Benutzers zu erlauben. OpenID Connect standardisiert diesen Bereich und wäre, wenn ich mich zwischen einem der beiden Protokollen entscheiden müsste, meine persönliche Wahl.

Quellen

ionos.de
entwickler.de
blog.oio.de
tools.ietf.org
openid.net