Über unsMediaKontaktImpressum
Linus Ezenwa 13. Oktober 2020

Delegierte Zugriffsverwaltung für Internetanwendungen

Wie OAuth 2.0 und OpenID Connect zur Benutzerauthentifizierung und -autorisierung verwendet werden

In dieser schnelllebigen Zeit hat das Internet dazu beigetragen, dass Digitalisierung und Globalisierung sich durchgesetzt haben. Als Folge davon sind zahlreiche Internetanwendungen und -plattformen entstanden, auf denen Einzelpersonen Online-Identitäten, Profile und digitale Daten erstellen müssen. Dabei entstand die Notwendigkeit, diese Daten sicher aufzubewahren und zu wissen, wann man Zugang zu ihnen gewähren muss.

Durch Projekte wie Customer Identity and Access Management (CIM) bestehen Erfahrungen, wie delegierter Zugriff auf die Ressource gewährt wird, die der Benutzer freigeben möchte, und gleichzeitig hohe Sicherheit für andere Daten gewahrt bleibt. Dies wurde mit Hilfe eines Protokolls namens OAuth 2.0 in Verbindung mit OpenID Connect erreicht. In diesem Beitrag wird das allgemeine Konzept der delegierten Zugriffsverwaltung für Internetanwendungen unter Verwendung des oben genannten Protokolls erläutert. Aber bevor man in die Tiefe einsteigt, wie dies mit Hilfe des oben genannten Protokolls erreicht wird, muss zunächst die Frage beantwortet werden, warum die Autorisierung delegiert wird. Diese Hintergrundinformationen können hilfreich sein, um zu verstehen, was die Notwendigkeit einer delegierten Autorisierung von Webanwendungen von Drittanbietern angetrieben hat. Erst im nächsten Schritt wird im Detail auf die Einführung des OAuth-2.0-Protokolls, seine Terminologien und Funktionalität eingegangen, gefolgt von der Einführung von OpenID Connect und schließlich, wie beide Hand in Hand arbeiten, um ein standardisiertes Autorisierungs- und Authentifizierungsprotokoll zu erreichen.

Was ist delegierte Autorisierung?

Eine delegierte Benutzerautorisierung ist der Anwendungsfall, aus dem das OAuth-Protokoll stammt. Wie der Name schon andeutet, handelt es sich dabei um den Prozess, bei dem der Benutzer (der Ressourcen-Besitzer) einer Client-Anwendung (Client) Zugriff auf die bestimmten Daten eines Benutzers (Resource Server) gewährt, während die Benutzerauthentifizierung und die Zugriffskontrolle fest beibehalten werden, wobei die Hauptanwendung nur den angeforderten und genehmigten Zugriff auf die Client-Anwendung gewährt.

Warum eine delegierte Autorisierung?

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 man sehen kann, zeigt das obige Diagramm den OAuth-2.0-Autorisierungscodefluss. Die Schritte sind wie folgt:

  1. Der Ressourcen-Besitzer wird durch einen Klick auf die Connect mit Google-Taste zum Autorisierungsserver des Ressourcen-Besitzers weitergeleitet, wo er sich anmelden wird.

    Wenn der Client den Autorisierungsserver aufruft, stellt er dem Server einige Parameter zur Verfügung, die für die Autorisierungen erforderlich sind, beispielsweise: 
  • ÜberRedirect/ callback URIkann der Autorisierungsserver mit der Autorisierungsrückmeldung zurück zu den Clients gelangen. 
  • Client-ID ist die ID des Clients, die die Autorisierungsanfrage ausführt.
  • Der Antworttyp (Response Type) der Anfrage ist in diesem Fall ein (Autorisierungs-)Code. 
  • Der Umfang (Scope)enthält die Einschränkung, auf die die Client-Anwendung im Benutzerkonto zugreifen kann. Diese Informationen werden dem Benutzer dann im Pop-up-Fenster angezeigt.
  1. Bei der Benutzeranmeldung fordert der Autorisierungsserver die Zustimmung des Benutzers (Ressourcen-Besitzer) an.
  2. Wenn der Ressourcen-Besitzer seine Zustimmung erteilt, stellt der Server, der den Umleitungs-URI verwendet, dem Client den angeforderten Autorisierungscode zur Verfügung.
  3. Der Client ruft fortan unter Verwendung des Autorisierungs-Codes erneut den Autorisierungsserver auf und fordert ein Zugriffs-Token an. Der Server überprüft den Autorisierungs-Code und stellt dem Client nach der Gültigkeit das angeforderte Zugriffs-Token aus.
  4. Der Client verwendet dann das bereitgestellte Zugriffs-Token, um den Ressourcenserver account.google.com – einschließlich des geheimen Schlüssels des Clients, der sich auf dem Server befindet – aufzurufen und den Zugriff auf die Daten des Benutzers anzufordern, die in diesem Fall die Kontakte des Benutzers sind (contacts.google.com). Der Ressourcenserver validiert das Zugriffs-Token und stellt dem Client den Kontakt des Benutzers zur Verfügung.
  5. Hat der Client nicht nur den Zugriff auf die Kontakte des Benutzers (contacts.google.com), sondern auch auf die Fotos des Benutzers (photos.google.com) angefordert, so verweigert der Ressourcenserver dem Client nach Validierung des Zugriffs-Tokens den Zugriff auf photos.google.com, da der Umfang des Tokens auf die Kontakte des Benutzers beschränkt ist.
  6. Dasselbe gilt, wenn der Client versucht, auf die Standorthistorie des Benutzers zuzugreifen: dann verweigert der Ressourcenserver dem Client nach Validierung des Tokens den Zugriff auf lokation.google.com.

Wenn man den OAuth-2.0-Autorisierungsfluss genau ansieht, erscheint es vielleicht verwirrend, warum der Client den Autorisierungsserver wiederholt anrufen muss, wobei er zuerst den Autorisierungs-Code anfordert und ihn dann schließlich mit einem Zugriffs-Token austauscht. Das liegt einfach an der Art und Weise, wie der Autorisierungs-Code-Fluss funktioniert. Er bietet eine zusätzliche Sicherheitsschicht im gesamten Ablauf des Autorisierungsflusses, indem zunächst der Client über seinen weniger gesicherten Frontkanal (Frontend: Internet-Browser, dargestellt in den Schritten 1, 2 und 3) den Autorisierungs-Code anfordert und mit dem Autorisierungsserver austauscht und dann über seinen Rückkanal (hochgesicherter Backend-Code, dargestellt in den Schritten 4, 5, 6 und 7) den Autorisierungsserver unter Verwendung des erhaltenen Autorisierungs-Codes und des Client’s Secret erneut anruft, um dann den Autorisierungs-Code gegen ein Zugriffs-Token auszutauschen.

Das Zugriffs-Token ist ein sehr sensibles Datenelement oder besser ein Erlaubnisschein zum Ressourcenserver (der meist derselbe ist wie der Autorisierungsserver), das am besten über den gesicherten Rückkanal-Code ausgetauscht wird, wo zum Beispiel ein Hacker, Spyware oder Browser-Analyzer es nicht abfangen kann, im Gegensatz zum Austausch über den Frontkanal (Internet-Browser), wo die Browser-Anfragen leicht abgefangen werden können.

Natürlich haben nicht alle Webanwendungen Rückkanäle, wie oben beschrieben. Anwendungen wie beispielsweise Angular Application oder statische Single Page Applications (SPA), die auf reinem JavaScript basieren, laufen ausschließlich über den Frontkanal, daher passt die Autorisierung in diesem Fall einen anderen OAuth-2.0-Grant-Typ an, der impliziter Fluss genannt wird. Dieser Autorisierungsfluss findet nur auf dem Frontkanal der Webanwendung statt, und zwar auf eine Weise, dass der Browser, anstatt einen Autorisierungs-Code anzufordern (s. Schritt 1 in Abb. 2, Antworttyp: Code), direkt ein Zugriffs-Token anfordert (Schritt 1 in Abb. 2, Antworttyp als Token). In diesem Fall ist der Austausch des Autorisierungs-Codes gegen ein Zugriffs-Token auf dem Rückkanal nicht mehr notwendig. Wie gesagt, der Austausch des Zugriffs-Tokens im Frontkanal ist weniger sicher, da der Zugriffs-Token dem Browser ausgesetzt ist und von jemandem abgefangen werden kann.

OpenID Connect

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.

Wie man sehen kann, entspricht der OpenID-Connect-Autorisierungs-Code-Fluss weitgehend dem OAuth-2.0-Autorisierungs-Code-Fluss. Der Unterschied besteht darin, dass bei OpenID Connect neben den Profil-Scope ein zusätzlicher Scope namens openid im Scope aufgerufen wird (s. Abb. 3, Schritt 1, Scope). Wenn der Benutzer sich anmeldet und seine Zustimmung erteilt, verwendet die Anwendung die Openid-Token-Antwort vom Autorisierungsserver, um den Benutzer zu authentifizieren. In diesem Fall wird das Protokoll nicht nur für die Benutzerautorisierung, sondern auch für die Benutzerauthentifizierung verwendet. Wenn der Client den Autorisierungs-Code austauscht, erhält er im Gegenzug Zugriff und ID-Token. Der Client kann dann bei Bedarf den Ressourcenserver für weitere Benutzerinformationen anrufen.

Fazit

Der Beitrag verdeutlicht, wie OAuth 2.0 und OpenID Connect funktionieren und wie OAuth 2.0 verwendet wird, um Zugriffe auf Autorisierungsserver /APIs zu gewähren. Die Daten des Benutzers werden aus externen Systemen extrahiert, während OpenID Connect verwendet wird, um den Benutzer anzumelden und somit das Konto und die Daten des Benutzers im externen System für den Client zugänglich zu machen – natürlich auf der Grundlage des Umfangs (Scope) und der Zustimmung des Benutzers.

Zudem wurde das Grundkonzept von OAuth-2.0- und des OpenID-Connect-Protokolls erläutert, das die Implementierung von Authentifizierungs- und Autorisierungs-Verwaltungssystemen standardisiert hat. Während einige Organisationen ihre OAuth-Service-Systeme selbst entwickelt haben, adaptieren einige Drittanbieter-Services wie Auth0 oder Okta als externe Identitätsdienste für ihre Organisation [1].

Darüber hinaus wurde beschrieben, wie die Notwendigkeit einer delegierten Zugriffsverwaltung entstanden ist und wie OAuth 2.0 mit OpenID Connect die Problematik der Benutzerauthentifizierung und -autorisierung bei Internetanwendungen angegangen sind. Dieses Protokoll verwaltet nur die Authentifizierung und Autorisierung und überprüft nicht, was der Client mit den Benutzer-Daten und seiner Zustimmung machen will. Daher hängt die Sicherheit seiner Daten allein vom Eigentümer der Ressource ab. Man sollte immer genau darauf achten, welchen Webanwendungen Zugang zu Daten gewährt wird, und nie vergessen, den Umfang/Scope und die Zustimmung, die die Anwendung verlangt, zu überprüfen, bevor man seine Zustimmung gibt. Einige Anwendungen können trickreich genug sein, um in ihrem Umfang vollen Zugang zu dem Benutzerprofil zu verlangen. Nutzer erteilen so häufig die Zustimmung zum Lesen, Schreiben und Löschen. Sie sollten sich folglich genau überlegen, wann und welche Anfragen sie genehmigen.

Quellen
  1. Auth0
    Okta

Autor

Linus Ezenwa

Linus Ezenwa ist Consultant bei adesso und verfügt über mehrjährige Berufserfahrung als Business Consultant im Versicherungs- und Finanzdienstleistungssektor.
>> Weiterlesen
Das könnte Sie auch interessieren

Kommentare (0)

Neuen Kommentar schreiben