92 VIEWS

OAuth 2.0 – Ein Überblick

10.03.2021

OAuth steht für Open Authorization und ermöglicht die standardisierte Autorisierung bzw. Absicherung von Schnittstellen. OAuth2.0 wurde 2012 von der IETF veröffentlicht.

Motivation

Traditionell wurden Schnittstellen über die HTTP Basic Authentifizierung abgesichert. Dabei werden bei jeder Anfrage von Client zu Server der Benutzername und das Passwort in Base64 codiert und übertragen. Dabei ist der Transport zwar über HTTPS verschlüsselt, allerdings sind Benutzername und Passwort beim Empfänger einfach als Base64 zu entschlüsseln. Dies führt zum einen dazu, dass für jede Anfrage erneut die Autorisierung durchgeführt werden muss und zum anderen zu einer Sicherheitslücke, da die HTTP Basic Authentifizierung über keinerlei Verschlüsselungsmöglichkeit beim Empfänger selbst verfügt.

 

 

Problemstellung HTTP Basic

Max möchte, dass seine SportTrackingApp in seinem Namen ein Posting auf Facebook durchführen darf.

  1. Max gibt seine Credentials für Facebook in die SportTrackingApp ein.
  2. Die SportTrackingApp loggt sich als Max bei Facebook ein und führt das Posting durch.

Problem: Die SportTrackingApp verfügt über die geheimen Facebook Credentials von Max. Dies wird in der Fachsprache auch als Passwort-Antipattern bezeichnet und stellt ein absolutes No-Go dar.

Wie sich zeigt, ist der Einsatz von HTTP Basic Authentifizierung mit einigen Nachteilen verbunden. Der Einsatz von OAuth2.0 ermöglicht es, genau diese Nachteile zu eliminieren und darüber hinaus einige weitere Vorteile zu schaffen.

Funktionsweise OAuth2.0

Der Anwendungsfall: Max möchte, dass seine SportTrackingApp in seinem Namen ein Posting auf Facebook durchführen darf.

OAuth 2.0 Flow
Abbildung 1: OAuth 2.0 Flow, Quelle: Eigene Darstellung

1) SportTrackingApp (Client) kontaktiert den Autorisierungsserver von Facebook und fordert die Berechtigung an, um einen Beitrag im Facebook (Ressource Server) für Max (Ressource Owner) erstellen zu dürfen.

2) Der Autorisierungsserver von Facebook kontaktiert Max (Ressource Owner) und erfordert einen Login.

3) Max (Ressource Owner) übermittelt die Logindaten an den Autorisierungsserver.

4) Der Autorisierungsserver validiert den Login und autorisiert Max als Ressource Owner, dabei wird das Token in der Datenbank des Autorisierungsserver abgespeichert.

5) Der Autorisierungsserver übermittelt das Token an die SportTrackingApp (Client).

6) SportTrackingApp (Client) übermittelt das Token und den Beitrag (Ressource) gemeinsam an Facebook (Ressource Server)

7) Facebook (Ressource Server) kontaktiert den Autorisierungsserver  und überprüft somit die Gültigkeit des Tokens.

8) Im Erfolgsfall darf die SportTrackingApp (Client) den Beitrag (Ressource) auf Facebook (Ressource Server) für Max (Ressource Owner) erstellen.

Warum also OAuth2.0 nutzen?

Wie in obiger Funktionsweise beschrieben, kommen die Nachteile der HTTP Basic Authentifizierung nicht mehr zur Wirkung. Durch die Vereinheitlichung von Schnittstellen zum Austausch von Tokens führen Änderungen an Autorisierungsmerkmalen nicht unbedingt zur Anpassung an Schnittstellen, da die Authentifizierung von der Autorisierung entkoppelt ist. Die sonst schwergewichtige Autorisierung muss nicht in vollem Umfang in Anwendungen integriert werden, stattdessen kann die Clientimplementierung von OAuth2.0 in Kombination mit bestehenden Autorisierungsservern verwendet werden. Anwendungen können sich so auf ihre Kernfunktionalitäten konzentrieren und das große und komplexe Thema Autorisierung von der Anwendung entkoppeln. Um unterschiedlichen Anwendungsfällen gerecht zu werden, lassen sich in OAuth2.0 unterschiedliche Grant Types verwenden. Grant Types regeln, wie die Autorisierung genau ablaufen soll. Im obigen Beispiel wurde als Grant Type Implicit Grant verwendet. Dabei stellt der Autorisierungsserver direkt ein Token aus.

Bekannte OAuth 2.0 Anwendungen in der Praxis

  • Amazon
  • Google
  • Facebook
  • Twitter

Die Rolle von Open ID Connect

Wenn man sich mit der Thematik beschäftigt, selbst so ein Autorisierungssystem aufzusetzen, kommen einige Fragen auf. OAuth2.0 ist zwar ein Autorisierungsframework, bietet aber keine Authentifizierung an. Die Authentifizierung von Identitäten übernimmt an dieser Stelle dem Standard gemäß das Open ID Connect Protokoll. Das im Rahmen des Open ID Connect eingesetzte Token ist in der Regel ein typisches JSON Web Token (JWT)Ob also ein reines OAuth2.0 oder doch die Kombination mit Open ID Connect notwendig ist, hängt vom Anwendungsfall ab. In vielen Anwendungsfällen ist es nötig, nicht nur Zugang zu einer Ressource zu ermöglichen, sondern eine Authentifizierung durchzuführen. Dies ist insbesondere dann der Fall, wenn benutzerbezogene Zugriffsrechte oder Informationen verarbeitet werden sollen. Sobald also letzteres zutrifft, empfiehlt sich der Einsatz von Open ID Connect.

Was brauche ich, um OAuth2.0 zu nutzen?

Generell muss unterschieden werden, welche Rolle die Anwendung im OAuth2.0 Kontext spielen soll. Für den gesamten OAuth2.0 Prozess wird ein OAuth2.0 Provider (Ressource-Server und ein Autorisierungsserver) benötigt, sowie ein OAuth2.0 Client, welcher auf die geschützten Ressourcen zugreifen möchte. Da in den meisten Anwendungsfällen nur eine der Schichten benötigt wird, ist es wichtig, zu verstehen, wo angesetzt werden muss.

 

Client

Der Client greift auf die geschützten Ressourcen zu. Im obigen Beispiel ist der Client die SportTrackingApp. Der Client hat die Aufgabe, die Berechtigung beim OAuth2.0 Server anzufragen und nach erfolgreicher Bestätigung eine Ressource an den OAuth2.0 Server inklusive Token zu übermitteln.

 

Autorisierungsserver

Der Autorisierungsserver stellt dem Ressource Owner eine Login Maske bereit. Nach erfolgreichem Absenden des Logins vom Ressource Owner zum Autorisierungsserver überprüft dieser den Login und speichert das Token in seiner Datenbank. Anschließend übermittelt der Autorisierungsserver das Token an den Client. Wenn im späteren Verlauf der Ressourcenserver den Autorisierungsserver kontaktiert, muss dieser das Token validieren und einen Erfolg oder den Fehlschlag mitteilen.

 

Ressourcenserver

Der Ressourcenserver empfängt vom Client ein Token sowie Content, welcher gespeichert werden soll. Das Token wird an den Autorisierungsserver zur Validierung übermittelt. Je nach dem, ob die Validierung durch den Autorisierungsserver erfolgreich verläuft oder nicht, wird der Content des Clients gespeichert.

 

Fazit

Zusammenfassend lässt sich festhalten, dass OAuth2.0 eine gute Möglichkeit bietet, die Autorisierung von Anwendungen für geschützte Ressourcen abzubilden. OAuth2.0 selbst besteht aus einem Autorisierungsserver für die Autorisierung eines Anforderers, sowie einem Ressourcenserver, welche die geschützten Daten beinhaltet und einem Client, welcher auf die Ressourcen zugreifen möchte. Durch die Vereinheitlichung von Schnittstelle und Login wird nicht nur die Benutzererfahrung verbessert, sondern auch der Aufwand für Anpassungen an Schnittstellen reduziert. Durch die flexible Integrationsfähigkeit mit bestehenden Autorisierungsservern / Ressourcenserver lassen sich kleine Anwendungen gut anbinden, ohne die Gesamtheit eines komplexen Autorisierungssystems bereitstellen zu müssen.

Je nach Anwendungsfall benötigt der Ressourcenserver weitere Informationen über den Anforderer. Dabei kommt Open ID Connect zum Einsatz. Open ID Connect schließt die Lücke von OAuth2.0 durch Hinzufügen der Authentifizierungskomponente. Dadurch ergibt sich die Möglichkeit, unterschiedliche Services mit dem selben Autorisierungsserver zu unterstützen.


Quellen

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*Pflichtfelder

*