Was ist OAuth?
OAuth ist als Internetprotokoll ein wichtiger Standard für die Sicherheit von Internet-Anwendungen und Apps.
OAuth 2.0 bzw. bald OAuth 2.1 ist das branchenübliche Protokoll und definiert ein Framework für die Autorisierung im Web.
Typische Anwendungsfälle & Use Cases für OAuth
Wenn ihr einen google Account nutzt und diesen zur Autorisierung Eures GitHub Accounts nutzt, dann ist das ein typischer OAuth-UseCase.
- Eure Anmeldung am GitHub Account erfordert dann keinen weiteren Benutzer, sondern nutzt die über den google Account definierte eMail-Adresse.
- Auch ein weiteres Passwort bleibt Euch erspart, weil dafür zwischen dem google Dienst und GitHub nur ein Secret ausgetauscht wird.
- Der GitHub Dienst wird im Gegenzug dafür, über den google Account, nur mit den von Dir autorisierten Informationen, etwa der eMail Adresse, versorgt.
OAuth ermöglicht den sicheren Komfort-Login
OAuth ermöglicht für Anmelde- und Autorisierungen somit einen Komfort-Login, weil es dem Nutzer eines webbasierten Dienstes erspart weitere Account-Daten zu erstellen und zu verwalten.
„OAuth macht das Internet ein gutes Stück weit sicherer.“
Eine OAuth-Flow ist dazu konzipiert kontrollierte Zugriffe auf APIs mit präzisen Berechtigungen ohne Passwort-Nutzung zu ermöglichen. OAuth-Verfahren ersetzen also die noch weit verbreitete Praxis einer Vielzahl von Logins und vermeiden somit die Verteilung von Account- und Anmeldedaten an eine schier endlose Anzahl von Server und Clients; zumal viele User immer noch identische Passwörter für unterschiedliche Accounts nutzen.
Vorteile der OAuth-Implementation
- Sicherheit für die Nutzung web-basierter Dienste
- Vermeidung zusätzlicher Passwort Nutzung für jeden autorisierten Service
- zentrales Passwort-Management via Token-Handling
- Möglichkeit autorisierten Diensten jederzeit die Autorisation zu entziehen, ohne dabei Passwörter ändern zu müssen
Wie funktioniert der OAuth-Secret-Flow?
Wer Web-Dienste sicher nutzen will, weiß dass dazu ein sicheres Passwort mit dem entsprechenden Benutzer und ein per SSL geschützter Login – siehe TLS-Protokoll – erforderlich sind.
Für die Komfort-Anmeldung mit OAuth braucht ein per OAuth angebundener Dienst am Client kein gewöhnliches Passwort.
Token Flow mit dem Autorisierungs-Server
Statt dessen wird ein sogenanntes Token als Secret, genutzt dass geheim zwischen dem OAuth-Autorisierungsserver und dem per OAuth autorisierten Webservice ausgetauscht wird.
Der Autorisierungs-Server ist eine zentrale Instanz für die Autorisierung von Services per Anmeldung und Registrationsverfahren.
Konzept: Separation of Concerns
Dieses Sicherheitskonzept separiert die Rolle des Clients von der des Benutzers in der Rolle des Ressourcenbesitzers (Rescource Owner).
Autorisierungsserver und Multi-Faktor-Authentifizierung
Autorisierungsserver bieten inzwischen fast ausnahmslos eine Multi-Faktor-Authentifizierung an, die meist über zwei Faktoren genutzt wird und daher dann auch als Zwei-Faktor-Authentifizierung bezeichnet wird.
Wird das OAuth-2.0-Framework [RFC6749] genutzt, ermöglicht dies den Clients den Zugriff auf geschützte Ressourcen durch den Erhalt eines Zugriffstoken, das als eine Zeichenkette definiert ist, die eine Zugriffsberechtigung für den Client repräsentiert. Genau dieses Token gestattet dem Client als
Besitzer eine Resource ohne weitere Identitätsnachweise direkt zu verwenden.
Token werden also von einem Autorisierungsserver mit der Zustimmung des Ressourcenbesitzers an Clients Genehmigung des Ressourceneigentümers ausgestellt.
Der Client verwendet das Zugriffstoken, um auf die geschützten Ressourcen zuzugreifen, die vom Ressourcenserver gehostet werden.
Diese OAuth-2.0-Spezifikation beschreibt, wie man geschützte Ressourcen anfordert, wenn
OAuth-Zugriffstoken genutzt werden.
Diese Spezifikation definiert die Verwendung von Bearer-Token über HTTP/1.1
[RFC2616] mit Transport Layer Security (TLS) [RFC5246] für den Zugriff auf
geschützten Ressourcen.
Mit Implementierung der OAuth-Spezifikation wird TLS obligatorisch, also verpflichtend, wobei andere Spezifikationen diese OAuth 2.0 Spezifikation für die
Verwendung mit anderen Protokollen erweitern können.
OAuth-2.0-Spezifikationen
Die Spezifikationen von OAuth-2.0 sind zwar für die Verwendung von Access Tokens (Zugriffstokens) konzipiert, die aus OAuth 2.0-Autorisierungsflows für den Zugriff auf OAuth-geschützte Ressourcen gelten, darüber hinaus definiert die OAuth 2.0 Spezifikation eine allgemeine HTTP-Autorisierungsmethode, die mit Bearer-Tokens verwendet werden kann, um auf alle Ressourcen einer Quelle zuzugreifen, die durch diese Bearer-Token geschützt sind.
Bearer-Auth-Schema und Bearer Token
Das Bearer-Authentifizierungsschema ist in erster Linie gedacht für Server-Authentifizierung unter Verwendung der WWW-Authenticate und Authorization
HTTP-Header gedacht, schließt aber seine Verwendung für die Proxy-Authentifizierung nicht aus.
Ein Bearer Token (auch Inhaber-Token) ist ein Nachweis in Form einer digitalen Wertmarke mit der Eigenschaft, dass jede Partei die im Besitz dieses Token ist (ein Token-„Inhaber“) die für das Token geltenden Berechtigungen in beliebiger Art und Weise nutzen kann.
Bei der Verwendung eines Bearer-Tokens muss der Token-Inhaber KEINEN Besitz von kryptografischem Schlüsselmaterial nachweisen, es reicht der Nachweis des Bearer Tokens.
Ressource Owner
OAuth bietet eine Methode, mit der Clients auf eine geschützte Ressource eines Ressource Owner (Ressourceneigentümer) zugreifen können.
Authorization Grant
Im allgemeinen Fall muss ein Client, bevor er auf eine auf eine geschützte Ressource zugreifen kann, zunächst über eine Autorisierung eine grundlegende Berechtigung vom Ressourceneigentümer einholen und dann die Berechtigung gegen ein Zugriffs-Token austauschen.
Access Token
Das Access Tokens (Zugriffstokens) repräsentiert den Umfang, die Dauer und andere Attribute, die durch die erteilte Berechtigung gewährt werden. Der Client greift auf die geschützte Ressource zu, indem er das
Zugriffstoken an den Ressource Server übermittelt.
Authorization Server
In einigen Fällen kann ein Client direkt seine eigenen Anmeldeinformationen einem Authorization Server (Autorisierungsserver) vorlegen, um um ein Zugriffstoken zu erhalten, ohne zuerst eine Berechtigung von einem Ressourceneigentümer zu erhalten.
Resource Server
Das Access Token stellt eine Abstraktion dar und ersetzt verschiedene Autorisierungskonstrukte (z. B. Benutzername und Passwort, Assertion) für ein einziges Token, das vom Ressourcenserver verstanden wird. Diese Abstraktion ermöglicht die Ausstellung von Zugangstokens, die für einen kurzen Zeitraum gültig sind, und außerdem muss der Ressourcenserver nicht mehr eine Vielzahl von Authentifizierungsverfahren verstehen.
OAuth-2 – Abstract Protocol Flow
Der in der Abbildung Abstract Protocol Flow dargestellte abstrakte OAuth 2.0-Ablauf beschreibt die Interaktion zwischen dem Client, dem Ressourcenbesitzer, dem Autorisierungsserver und dem Ressourcenserver.
(E) Der Client fordert die geschützte Ressource beim Ressourcen Server an und authentifiziert sich durch Vorlage des Zugriffstokens.
(F) Der Ressourcenserver validiert das Zugriffstoken, und wenn es gültig ist, wird die Anfrage bearbeitet.
OAuth spezifiziert auch semantische Anforderungen an das Token, das in Schritt (D) zurückgegeben wird.
Update für den Security-Standard OAuth 2.0 zu OAuth 2.1
Die OAuth-2.0-Spezifikation ist inzwischen „etwas in die Jahre gekommen“ und wird von diversen RFCs flankiert um grundlegend sichere Datentransfers zu gewährleisten.
Update zur OAuth-2.1-Spezifikation
Mit diesem Ziel hat die Internet Engineering Task Force damit beginnen, das aktuelle OAuth 2.0-Framework auf die Version 2.1 zu aktualisieren, die alle aktuellen Empfehlungen und bewährten Verfahren – siehe auch rund um die Spezifikation umfasst.
Mitsamt aller Nebendokumentationen ist ein Dschungel mit einem Labyrinth diverser technischer Dokumentationen entstanden, die Entwickler*innen verstehen müssen, wenn sie sich den Anforderungen zur sicheren Authentifikation befassen.
Änderungen mit der neuen OAuth-Spezifikation
Die ursprüngliche RFC6749-Spezifikation stammte bereits aus dem Jahr 2012. Weil der implizite Token-Flow als veraltet gilt, ergeben sich auf diesen Angriffsvektor bezogen die größten Änderungen.
So ersetzt der Authorization Code Flow mit PKCE (RFC7636) die bisherigen Empfehlungen für bestimmte Anwendungsfälle.
Zusätzliche Sicherheitsmaßnahmen realisieren einen Schutz vor Cross-Site-Request-Forgery-Angriffen (CSRF-Angriffe). Mit der Umsetzung der Empfehlungen für Redirect-basierte Flows lassen sich Vorfälle wie die Azure Account Takeover-Schwachstelle vermeiden.
