Die Notwendigkeit einer delegierten Autorisierung ergab sich aus der Schwierigkeit, einer Website die Autorisierung von Daten zu gewähren: Das bedeutet, die Eingabe von Benutzernamen, E-Mail-Adressen oder Passwörtern für die Anwendung, in der die Daten gespeichert werden.

Vor einigen Jahren wurde die Autorisierung bei Webanwendungen so implementiert, dass die Webanwendung nur die Möglichkeit hat, den vollen Zugang zu einem Konto zu beantragen, um bestimmte Daten zu erhalten, die benötigt werden. Zum Beispiel muss der Benutzer seine E-Mail-Adresse, Benutzernamen und Passwort an eine Client-Anwendung eines Drittanbieters weitergeben, die Zugang zu seinen E-Mail-Kontaktdaten haben möchte. Einige Anwendungen wie Dropbox oder Yelp haben vor Jahren eine solche Autorisierungsmethode implementiert, die ineffizient war; damals war die Technologie allerdings noch nicht so weit entwickelt wie heute.

Yelp hat vor einigen Jahren die oben beschriebene Empfehlungsstrategie entwickelt, um so viele Benutzer wie möglich dazu zu bringen, sich für ein Yelp-Konto anzumelden. Folgendermaßen hat dies funktioniert: Nachdem der Benutzer sich für das Yelp-Konto registriert hat, bittet Yelp ihn, seinen Kontakten zu empfehlen, sich ebenfalls bei Yelp anzumelden. Um dies zu erreichen, sollte er auswählen, welche E-Mail-Dienste er nutzt – im genannten Fall Google Mail. Dann gibt er seine Gmail-Adresse und sein Gmail-Passwort ein. Dadurch erhält Yelp Zugang zu seinem Gmail-Konto, wo Yelp entscheiden kann, seine Google-Kontakte zu durchsuchen und eine Einladung an seine Kontakte zu verschicken, die sich bisher nicht bei Yelp angemeldet haben.

Wie man sehen kann, ist die Autorisierungsmethode von Yelp nicht zuverlässig und bequem, da der Benutzer seine E-Mail-Adresse und sein Passwort an Yelp weitergeben muss. Er erlaubt Yelp nicht nur den Zugang zu seinen Kontakten, sondern riskiert auch, dass Yelp vollen Zugang zu seinem E-Mail-Konto hat, das heutzutage der Hauptschlüssel zu anderen Internet-Konten ist. Darüber hinaus kann Yelp auch auf seine Google-Fotos, Dokumente, seinen Standortverlauf und andere Google-Funktionen zugreifen.

Es kann natürlich unbeabsichtigt sein, dass Yelp vollen Zugriff auf sein Google-Mail-Konto verlangt. Wahrscheinlich liegt es daran, dass es damals keine bessere Möglichkeit gab, Yelp nur Zugriff auf seine Google-Kontakte zu gewähren. Hier stellte sich die Frage nach der delegierten Autorisierung und wie man Webanwendungen von Drittanbietern Zugriff nur auf die benötigten Ressourcen gewähren kann, anstatt vollen Zugriff auf sein Konto zu gewähren. Dieses Problem wurde mit dem OAuth-2.0-Protokoll gelöst.

Wie wird Autorisierung delegiert?

Wie die meisten Internetanwendungsnutzer vielleicht erfahren haben, ist die delegierte Autorisierung etwas, der die meisten Leute oft begegnen werden. Wenn zum Beispiel ein Pop-up-Fenster auf dem Benutzerbildschirm erscheint, das sagt: "Yelp möchte Zugang zu Ihren Google-Kontakten haben. Wollen Sie dies erlauben?" Darunter kann der Benutzer auf 'Ja' klicken, um die Genehmigung zu erteilen, oder auf 'Nein', um die Anfrage abzulehnen. Dies wird als delegierter Zugriff bezeichnet, das heißt, die Website kann auf seine Google-Kontakte zugreifen, ohne der Website seine E-Mail-Adresse und Ihr Passwort zu geben.

Open Authorization (OAuth) 2.0 ist die neueste Version von OAuth. Es handelt sich dabei um ein Protokoll, das seit Jahren als eine der besten Methoden der Branche angepasst wird, um die Autorisierungs-, Sicherheits- und Wartungsherausforderungen im Web-Autorisierungssystem zu bewältigen und so das oben beschriebene Problem leichter zu lösen.

Hier wird erklärt, wie das OAuth-2.0-Protokoll funktioniert, um eine delegierte Autorisierung mit Hilfe des Autorisierungsflusses zu erreichen. Aber um den Prozess der Benutzerautorisierung mit OAuth 2.0 zu verstehen und zu wissen, wie dieses Protokoll funktioniert, ist es wichtig, sich seine Terminologien zu verdeutlichen.

1. Der Ressourcen-Besitzer (Resource Owner) ist der Benutzer, der die Daten besitzt, auf die die Webanwendung zugreifen will und die sie daher anfordert. Beispiel: Der Ressourcen-Besitzer ist der Benutzer, der sich einloggt und auf 'Ja' klickt, um der Drittanbieter-Webanwendung den Zugriff auf die Daten zu gestatten, oder auf 'Nein', um den Datenzugriff zu verweigern.
2. Der Client ist die Webanwendung des Drittanbieters, die die Genehmigung für den Zugriff auf die benötigten Daten angefordert hat. Beispiel: yelp.com.
3. Autorisierungsserver (Authorization Server) ist der Server, auf dem der Ressourcen-Besitzer seine Zustimmung zu den angeforderten Daten genehmigt oder verweigert. Beispiel: Google-Autorisierungsserver (accounts.google.com).
4. Der Ressourcenserver (Resource Server) ist der eigentliche Server an einem physischen Ort, auf dem die Daten des Ressourcen-Besitzers gespeichert sind. Er ist das Ziel, zu dem der Client (yelp.com) nach Erhalt der Genehmigung gelangen möchte. Ein Beispiel ist die Google-Kontakte-API.
5. Autorisierungserlaubnis (Authorization Grant) ist die tatsächliche Erlaubnis des Benutzers, nur auf die angeforderten Daten zuzugreifen. Sie erfolgt in Form eines kurzen Gültigkeits-Codes, der dann am Autorisierungsserver gegen einen Zugriffs-Token (Access Token) eingetauscht wird.
6. Redirect Uniform Resource Identifier (Redirect URI)ist der Pfad, dem der Autorisierungsserver folgt, um zurück zur Client-Anwendung zu gelangen. Wenn der Zugriff gewährt wird, wird festgelegt, wohin er als nächstes gehen soll.
7. Das Zugriffs-Token (Access Token) ist der Hauptschlüssel, den der Client benötigt, um Zugriff auf die autorisierten Benutzerdaten zu erhalten, die sich auf dem Ressourcenserver befinden. Ein Beispiel sind die Google-Kontakte des Benutzers.

Wie Sie vielleicht bemerkt haben, war man damit beschäftigt, sich über den Zugang zu einem Benutzerkonto Gedanken zu machen sowie darüber, wie die Benutzerautorisierung und die delegierte Zugriffsverwaltung bei Webanwendungen mit dem OAuth-2.0-Protokoll erfolgt. Man ist aber nicht wirklich darauf eingegangen, wie der Benutzer vom Autorisierungsserver authentifiziert wird, während seine Erlaubnis angefordert wird. Da OAuth 2.0 außerdem ein standardisiertes Protokoll für die Benutzerautorisierung ist, gab es keine standardisierte Methode der Benutzerauthentifizierung. Webanwendungen, die das OAuth-2.0-Protokoll für die Benutzerautorisierung anpassen, haben auf ihre eigene Weise das Protokoll auch für die Benutzerauthentifizierung erweitert und verwendet. Dies führte zu einer nicht standardisierten und nicht harmonisierten Lösung für die Benutzerauthentifizierung in OAuth 2.0. Hier kommt OpenID Connect ins Spiel. OpenID Connect ist eine standardisierte Identitätsschicht, die über dem OAuth-2.0-Protokoll aufgebaut ist. Sie ermöglicht es, allen Arten von Client-Anwendungen, die Identität des Endbenutzers auf der Grundlage der vom Autorisierungsserver durchgeführten Authentifizierung zu überprüfen und grundlegende Profilinformationen über den Endbenutzer auf interoperable und REST-ähnliche Weise zu erhalten.

OpenID Connect ist nur eine Erweiterung des OAuth-2.0-Protokolls, welches OAuth 2.0 einige wichtige Funktionen hinzufügt und damit die Lücke im OAuth-2.0-Authentifizierungsanwendungsfall schließt. Es bringt die folgenden Funktionen mit sich:

1. ID-Token enthält die ID des Benutzers und ermöglicht es der Client-Anwendung, einige grundlegende Informationen über den Benutzer abzurufen, indem sie zeitgleich das ID-Token anfordert, während sie Autorisierungs-Code oder Zugriffs-Token anfordert (s. Abb. 3, Schritt 1, Scope: openid).
2. UserInfo Endpoint enthält weitere Informationen über den Benutzer. Wenn die abgerufenen Benutzerinformationen unter Verwendung des Zugriffs-Tokens nicht ausreichen, kann der Client weitere Benutzerinformationen am UserInfo-Endpunkt anfordern.
3. Ein Standardsatz von Scope kann für die einfache Implementierung in Webanwendungen genutzt werden.
4. Einestandardisierte Implementierung der Benutzerauthentifizierung und -autorisierung kann im OAuth-2.0-Protokoll über Webanwendungen hinweg verwendet werden.