Sichere Autorisierung mit dem OAuth 2.0 Framework

Der Begriff OAuth 2.0 (abgekürzt OAuth2) ist in vielen Schichten bei IT-Entscheidern, technischen Leitern und Mitarbeitern aus Fachabteilungen in der Anwendungs- und Webentwicklung sehr wohl bekannt. Auch die Endanwender kommen immer häufiger mit diesem Protokoll in Berührung, ohne jedoch wirklich etwas davon zu bemerken. Oftmals herrscht jedoch Uneinigkeit über die genaue Definition der dahinterstehenden Technik und Verwendung, die hinter diesem Begriff steht. Wir werden Ihnen hier nun aus einer zunächst einfachen Sichtweise OAuth2 etwas näher beschreiben. In weiteren Artikeln gehen wir dann auch tiefer in technische Details.

Grundsätzlich handelt es sich bei OAuth2 nicht um eine API oder einen speziellen Dienst. Vielmehr steht der Begriff für einen etablierten Sicherheitsstandard und ein Protokoll für Funktionen, um für verschiedene Medien wie Geräte, Datenbanken und Webseiten einen sicheren Zugang zu ermöglichen. Das Protokoll läuft dabei auf dem im Internet verwendeten HTTP-Standard und ist somit weitreichend einsetzbar. Derzeit existieren zwei voneinander unabhängige Versionen mit OAuth 1.0a und OAuth 2.0, wobei letzteres auch keine Abwärtskompatibilität bietet.

Aus Anwendersicht ermöglicht OAuth2 einem Kunden das sichere Benutzen von Anwendungen und Diensten durch eine passwortlose Authentifizierung. Auf vielen Webseiten und für zahlreiche Anwendungen kann ein Benutzer seinen vorhandenen OAuth2-kompatibles Benutzerprofil von beispielsweise Facebook, Twitter oder Google verwenden. Beim Login auf einer Drittanbieter-Webseite wählt der Benutzer nur die entsprechende Option wie „Mit Facebook anmelden“. Dort erteilt er dem Drittanbieter entsprechende Zugriffsrechte und wird sofort wieder auf dessen Seite geleitet und mit seiner Facebook-Kennung eingeloggt. Der Anbieter nutzt hier den Authentifizierungs- und Autorisierungsstandard OAuth 2.0 und kann somit sehr sicher und komfortabel auf die Ressourcen des Benutzers zugreifen.

Damit diese vereinfachte Autorisierung system- und netzübergreifend funktionieren kann, muss für den passwortlosen Zugriff auf die Benutzerressourcen eine klare Struktur vorhanden sein. Ein Authorization-Server koordiniert alle Vorgänge und kontrolliert die Autorisierungsszenarien. Wenn ein Benutzer bei einem Anbieter wie Facebook oder Google registriert ist, spielt dieser Dienst die Rolle des Identity-Providers. Als sogenannter Resource-Owner (Besitzer der Benutzerdaten) kann er Drittanbietern (Clients) nach Freigabe durch den Benutzer einen passwortlosen Zugriff auf dessen Ressourcen wie Benutzername, Passwort und weitere Benutzerdaten ermöglichen.

Dafür wird nun ein OAuth2-kompatibler Resource-Server verwendet, der aus einer Client-ID des Service und einem zusätzlichen und geheimen Client-Schlüssel (Secret) ein gültiges Token erzeugt. Dieses Token ist dann für alle weiteren Logins, Abfragen und Authentifizierungen zwischen den Beteiligten immer mit zu übertragen und stellt als verschlüsselte Eintrittskarte eine sichere und gültige passwortlose Autorisierung dar. Der Protokollfluss ist dabei klar geregelt. Der Client fragt beim Resource-Owner für eine Autorisierung an und erhält danach eine Genehmigung. Mit dieser Genehmigung wird nun in einem 2. Schritt beim Authorization-Server um ein Token angefragt. Erst nach dieser Zuweisung kann der Client nun beim Ressource-Server die benötigten Daten abfragen.

Wenn ein Client nun zusätzliche Daten des eingeloggten Benutzers für beispielsweise einen Warenkauf in seinem Shop benötigt, kann er beim Resource Owner ein Access Token anfordern. Wenn dieser dem Serviceanbieter ein Access Token ausstellt, können mittels des Parameters Scope die Zugriffsberechtigungen gezielt geregelt werden. Wenn der Drittanbieter beispielsweise nach den Kundendaten fragt, so wird der Access-Server auch nur darauf Zugriff gewähren und den Gültigkeitsbereich (Scope) dahingehend eingrenzen. Als Ergebnis erhält der Client vom Autorization-Server ein Token mit ausschließlich den begrenzten Zugriffsrechten.

Bei jeder Änderung oder einer neuen Anfrage muss der Client ein neues Token beim Resource-Owner anfragen. Hierzu wird ein Refresh Token versendet und enthält auch automatisch das Zugriffstoken, um nicht bei jeder Neuanfrage auch eine erneute Autorisierung einholen zu müssen. Jedes Token enthält zudem eine begrenzte Gültigkeit. Wird in dieser Zeit die angeforderte Aktion nicht ausgeführt, erfolgt ein Timeout und erhöht dadurch automatisch die Sicherheit des Protokolls. Das Timeout liegt typischerweise bei wenigen Sekunden bis einige Minuten.

Im OAuth2-Protokoll existieren mehrere unterschiedliche Berechtigungstypen (Grant-Types), die den Umfang der zur Übertragung benötigten Daten reglementieren und damit die Kommunikation sicherer gestalten können. Die derzeitigen Grant-Types haben dabei folgende Sicherheitsverfahren:

Mit dem aktuellen Sicherheitsprotokoll OAuth2 wird sehr einfach eine delegierte Autorisierung von Benutzern ermöglicht. So kann beispielsweise ein Google-Konto bei allen OAuth2-kompatiblen Diensten und Anbietern sehr einfach für eine unkomplizierte und schnelle Registrierung sowie einem Datenaustausch verwendet werden. Außerdem stehen dem Benutzer weitreichende Möglichkeiten wie die Kontrolle und der Entzug von Zugriffsrechten Dritter zur Verfügung. Dies ermöglicht eine transparente Verwaltung von Kontodaten und Login-Zugängen. Der jedoch wichtigste Aspekt zur Anwendung von OAuth2 ist die Tatsache, dass Benutzer nur noch ein Benutzerkonto bei einem beliebigen Anbieter benötigen, um sich bei allen kompatiblen Client-Diensten komfortabel anmelden zu können.

Neugierig geworden? – Nutzen Sie doch einfach unsere kostenfreien technischen Folgeartikel zu diesem Thema, wir freuen uns auf Sie.