OAuth 2.0 - Authorization Grant Types resource owner password credentials

Der OAuth 2.0 Grant-Type „password“

Mit der aktuellen OAuth 2.0 Spezifikation bekommt man eine vereinfachte und schnelle Möglichkeit, um die wesentlichen Kundendaten wie Benutzername und Passwort für einen Autorisierungsvorgang gezielt abfragen und übertragen zu können. Mit dem OAuth2-Grant „passwort“ kann ein sogenannter Kennwortberechtigungsnachweis für Ressourceneigner angefragt und erteilt werden. Dieses Verfahren wird in der Regel zwischen dem Inhaber der Kundendaten wie beispielsweise Google und einem Drittanbieter wie beispielsweise dem Datenspeicherdienst Dropbox für eine vereinfachte Kundenregistrierung verwendet.

Wenn ein Kunde die Dienstleistungen eines Dienstleisters, eine App oder einen Webservice in Anspruch nehmen möchte, so muss er sich auf deren Webseite oder in der App entweder komplett neu oder über einen schnelleren Zugang mittels eines bestehenden Social-Media-Kontos wie beispielsweise Google registrieren bzw. anmelden. Nutzt der Kunde den Zugang über sein vorhandenes Google-Konto, so werden diese Anmeldeinformationen bei diesem Verfahren „direkt“ beim Dienstleister abgefragt. Die sonst übliche und gesicherte Weiterleitung zum Google OAuth2-Sicherheitsserver fällt hierbei weg. Der Anbieter kann nun direkt die Benutzerdaten und zusätzliche Informationen bei Google abfragen und den Kunden bei sich einloggen.

Das Autorisierungsverfahren für die Kennwort-Anmeldeinformation

Gegenüber den anderen Grant-Typen von OAuth 2.0 wird der Passwort-Grant nur für die Erteilung der Anmeldeinformationen mit Benutzername und Kennwort benötigt. Dieser Berechtigungsnachweis nutzt damit also ein vereinfachtes Autorisierungsverfahren, um einen Benutzer für die Dienstfreigabe bei einem Anbieter freizuschalten. Der OAuth2-Grant „passwort“ verwendet zudem einen vereinfachten Autorisierungs-Workflow und ist dadurch speziell für eigene mobile Apps und Webanwendungen prädestiniert. Den vermeintlichen Vorteil eines einfachen Workflows erkauft man sich aber mit einem erhöhten Sicherheitsrisiko. Den wesentlichen Unterschied erläutern die beiden folgenden Szenarien:

  • Wenn Sie sich beispielsweise bei Google mit Ihren dort hinterlegten Benutzerinformationen anmelden, so ist diese Kennwort-Anmeldeinformation für Google-Dienste gefahrlos zu verwenden. Solange Sie nur anbietereigene Apps oder Webanwendungen nutzen, bleibt der Berechtigungsschlüssel für die Kennwort-Anmeldeinformation bei Google.

  • Wenn Sie sich nun bei einem fremden Dienstleister direkt mit ihrem Benutzernamen und Kennwort über den Grant-Typ „passwort“ anmelden, so kann der Anbieter den Berechtigungsschlüssel sehr einfach speichern und für andere Zwecke vergleichsweise wie ein Generalschlüssel missbrauchen.

Der Autorisierungs-Flow im Detail

Gegenüber anderen OAuth 2.0 Grant-Typen werden bei „passwort“ andere und stark vereinfachte Verfahren genutzt. Bei dieser Art der direkten Autorisierung sind vorerst „nur“ noch die folgenden beiden Partner beteiligt:

  • Ein Benutzer, der sich bei einem Dienstleister, einer App oder Webservice anmelden und dessen Leistungen in Anspruch nehmen möchte.

  • Ein Client (Dienstleister als Webseite oder Web-Anwendung), der seinen Besuchern unterschiedliche Leistungen anbieten möchte.

In diesem Beispiel sehen wir vorerst nur noch eine Zwei-Wege-Kommunikation zwischen Benutzer und Anbieter. Dies sonst üblichen und gesicherten Autorisierungsschritte über einen OAuth 2.0 Provider fehlen hier gänzlich. Daraus ergibt sich nun der folgende Autorisierungsflow:

  • Ein Benutzer ruft die Webseite von einem Dienstanbieter auf und findet dort einen Anmelde- bzw. Registrierungsdialog. Gehen wir hier nun davon aus, dass der Benutzer dort noch nicht registriert ist. Über die obligaten Eingabefelder Benutzername und Passwort könnte der Dienstanbieter nun direkt Ihre Anmeldeinformationen von beispielsweise Google erfragen, um eine Anmeldung zu ermöglichen.

  • Wenn Sie hier nun Ihre Anmeldeinformationen eintragen und bestätigen, kann der Dienstanbieter bei Google sofort die Benutzerdaten auf direktem Weg und ohne weitere Autorisierung durch Sie anfordern. Darüber hinaus erhält der Dienstanbieter die Möglichkeit, weitere Benutzerinformationen von Ihnen abzurufen und diese erneut ungefragt zu verwenden.

Anstelle einer gesicherten und zusätzlichen Anfrage über einen OAuth 2.0 Provider verfügt der Dienstanbieter nun direkt über Ihre geheimen Anmeldeinformationen bei Google. Diese Daten werden zudem offen übertragen und können im Browserverlauf gespeichert und jederzeit wiederverwendet werden. Zudem ist es dem Dienstanbieter mit diesen Daten ohne weiteres möglich, auf weiteren von Ihnen mit diesen Login-Informationen genutzten Plattformen ebenso direkten Zugang zu erhalten.

Vorsicht und Sicherheit an erster Stelle

Schnell gerät man als Benutzer in die Verlockung, sich bei neuen Dienstleistern, Apps und Webangeboten auf „direktem“ Wege mit seinen vorhandenen Registrierungsdaten aus beispielsweise Facebook oder Google anzumelden. Vor diesem Schritt sollte man jedoch unbedingt prüfen, ob es sich beim Login um ein vom Anbieter selbst generiertes Login mit Eingabefeldern handelt oder man beispielsweise über eine Schaltfläche vorab zu „seinem“ Provider (z.B. Google oder Facebook) für ein abgesichertes Login umgeleitet wird. In jedem Fall sollte man sorgfältig abwägen, ob und an wen man seine bereits vorhandenen Logindaten von Google oder Facebook weiterreicht. Manchmal könnte auch eine komplett neue Registrierung mit eigens dafür vorgehaltenen Phantasie-Benutzerdaten von Vorteil sein.

Nach oben