Der OAuth 2.0 Grant-Type „implicit“
In der aktuellen OAuth 2.0 Spezifikation ist ein spezieller Grant-Typ für eine vereinfachte Autorisierung vorgesehen worden. Mit dem Grant-Typ „implicit“ besteht somit für beispielsweise eine JavaScript-App die Möglichkeit, ein erforderliches Zugriffstoken „ohne“ den sonst üblichen Schritt über einen Autorisierungsserver direkt zu erhalten. Ähnlich wie beim OAuth2-Grant „authorization_code“ beginnt eine implizite Freigabe auf einer Clientseite wie beispielsweise dem Datenspeicherdienst Dropbox.
Ein neuer Benutzer muss sich dort entweder neu registrieren oder kann sich alternativ mit einem bestehenden Google-Konto direkt einloggen. Wird dieses vereinfachte Verfahren über Google verwendet, so öffnet Dropbox über einen Link ein Browserfenster des Google-Autorisierungsserver und bittet darin um Freigabe verschiedener Funktionen. Wenn der Benutzer die Anfrage bestätigt und die Funktionen freigibt, wird er sofort zu Dropbox über die beigefügte URI zurückgeführt. In der URL befindet sich dann auch ein Zugriffstoken um den Benutzer bei Dropbox freizuschalten.
Die Autorisierung Schritt für Schritt
Gegenüber dem relativ starken und sicheren Grant-Typ „authorization_code“ steht bei diesem Typ ganz bewusst ein vereinfachtes Handling im Vordergrund. Dies erkauft man sich jedoch mit einem nicht existenten zusätzlichen Sicherheitsverfahren und ist dadurch massiv angreifbar. Im direkten Vergleich der beiden Grant-Typen gibt es dadurch nun auch deutliche Unterschiede. Folgende Partner sind bei einem Autorisierungsprozess beteiligt:
-
Ein Benutzer, der eine App oder einen Webservice von einem Dienstleister wie beispielsweise Dropbox verwenden möchte.
-
Ein Dienstleister wie beispielsweise Dropbox als Client, der eine App, einen Webservice oder weitere Dienstleistungen für Benutzer anbietet.
-
Ein Provider wie beispielsweise Google, bei dem ein Benutzer mit seinen vollständigen Daten bereits registriert ist.
An dieser Stelle ähneln sich die beiden Grant-Typen noch sehr stark. Auf der Clientseite werden in der Regel unterschiedliche Anforderungen für die Dienstleistungen benötigt. Bei einer Anmeldung eines Benutzers müssen daher zuvor entsprechende Berechtigungen eingeholt werden. Dabei entsteht für den Benutzer das folgende Szenario bei einer Anmeldung:
-
Der Benutzer navigiert auf die Webseite des Anbieters. Um die Dienstleistungen von beispielsweise Dropbox letztendlich nutzen zu können, muss er sich dort entweder komplett neu registrieren oder kann sich mit einem bereits vorhandenen Konto bei beispielsweise Google direkt einloggen.
-
Bei Dropbox findet der Benutzer nun eine Schaltfläche „Mit Google registrieren“. Klickt er auf diesen Button, so wird er auf die Seiten von Google umgelenkt und bekommt dort einen Login-Dialog zu seinem bestehenden Kundenkonto. Nach der Eingabe der Anmeldedaten findet der Benutzer in einem Dialogfenster nun detaillierte Angaben, welche Daten und Berechtigungen Dropbox nutzen möchte.
-
Betätigt der Benutzer nun diese Berechtigungen, wird er sofort zu Dropbox zurückgeleitet und ist dort dann auch schon eingeloggt. Der Nutzung der Dienste steht somit nichts mehr im Weg.
Vereinfachte Protokoll- und Prozessschritte für den Client
Bis zu diesem Punkt besteht aus Sicht des Benutzers das Autorisierungsverfahren immer noch aus ähnlichen Schritten. Der immens verlockende Vorteil an dieser Autorisierung ist das vereinfachte Anmeldeverfahren bei einer Vielzahl an Clients, die eine auf dem OAuth 2.0 - Protokoll basierte Autorisierung anbieten. Mit einem vorhandenen Kundenkonto bei beispielsweise Google kann sich ein Benutzer mit all seinen Kundendaten schnell bei vielen Diensten anmelden und muss sich somit auch nur ein Kennwort merken. Für Dropbox als Client ergeben sich dabei die folgenden Prozessschritte, um einen Benutzer bei sich zu registrieren:
-
Wenn sich ein Benutzer über die Schaltfläche „Mit Google registrieren“ anmelden möchte, muss er zuerst über einen Login- oder Redirect-Dialog zu Google umgeleitet werden. Über verschiedenen Parameter werden zusätzliche Angaben wir client-id, redirect-uri und state gleich mitgeliefert. Dort werden dem Benutzer die erforderlichen Berechtigungen angezeigt und um Freigabe gebeten.
-
Wenn sich der Benutzer nun bei Google angemeldet hat und die Dropbox-Freigaben erteilt, wird er über die mitgelieferte URI sofort zu Dropbox zurückgeleitet. Dabei werden in der URL auch sofort ein Zugriffstoken und ein Zustand von Google mitgeliefert.
An dieser Stelle nun haben wir, für den Benutzer jetzt nicht mehr sichtbar, jedoch bereits ein gänzlich anderes Verhalten im Vergleich zum Grant-Typ „authorization_code“. Der Client, in unserem Beispiel eben Dropbox, kann das zurückgelieferte Token sofort verwenden und umgeht damit die gesicherte Anfrage beim Autorisierungsserver. Somit gehen wichtige Sicherungsparameter wie client_secret und code verloren bzw. werden nicht abgefragt. Einer Manipulation der „nackten“ URL-Parameter stehen somit Tür und Tor offen. Zudem steht auch kein Rückkanal zur Absicherung des Tokens und des Secrets mehr zur Verfügung.
Komfort oder Sicherheit?
An dieser Stelle drängt sich förmlich die Frage nach dem Komfort und der Sicherheit in einem Autorisierungsprozess auf. Der OAuth2-Grant „implicit“ wurde einst zur Vereinfachung der Autorisierung von JavaScript-Apps ersinnt. Im Praxiseinsatz zeigt sich jedoch schnell die große Gefahr des Missbrauchs. Der eigentliche Nutzen wird damit gegen Null geführt.
Bezüglich Datenschutz sind hier sehr große Bedenken zu erkennen. Zudem wird das Token offen übertragen und ist damit manipulierbar. Ein weiterer Aspekt ist die Tatsache, dass mit dem Grant-Typ „implicit“ das Token sogar im Browserverlauf gespeichert wird und über die Gültigkeitsdauer hinaus abrufbar bleibt. Die Verwendung dieses OAuth2 Grant-Typs wird aus diesen Gründen in der Regel nicht mehr empfohlen, da dieser nicht mehr den hohen Sicherheitsanforderungen im vollständigen Autorisierungsprozess entspricht.