Sobald man sich mit dem Thema OAuth-Spezifikation beschäftigt, wird klar, dass dieses Framework nicht für die Authentifizierung, sondern für die sogenannte „delegierte Autorisierung“ konzipiert wurde. Unabhängig davon, welche Variante verwendet wird, macht die offizielle Spezifikation deutlich, dass OAuth den Benutzern erlaubt, ihre privaten Ressourcen auf einer Website mit einer anderen Website zu teilen, ohne dabei ihre Anmeldeinformationen teilen zu müssen (D. Hardt, 2012). Diese Funktion kann Techniker und IT-Architekten dazu verleiten, im Hinblick auf Authentifizierungsprobleme schlechte Sicherheitsentscheidungen zu treffen, wenn sie versuchen, verschiedene OAuth-Abläufe in einem anderen Kontext zu übernehmen. Eric et al. warnten beispielsweise in ihren Studien vor der Verwendung von OAuth auf mobilen Geräten, da in diesen Fällen die Speicherung des Tokens nicht sicher ist oder willkürliche Umleitungsmechanismen verwendet werden. Diese Mechanismen stellen Sicherheitsprobleme dar, wenn sie nicht korrekt gehandhabt werden (Eric et. al., 2014). Dadurch, dass dieses Protokoll nicht auf Zugangsdaten wie Benutzernamen und Passwörtern basiert, wäre es für Szenarien geeignet, in denen die Benutzer sich nicht auf herkömmliche Weise authentisieren müssen (z. B. über Passwörter, Token oder Biometrie). Ein Beispiel dafür wären cloud-basierte Anwendungen. Generell müssen IT-Dienstleister zahlreiche Bestimmungen im Hinblick auf den Daten- und Zugriffsschutz einhalten. Dies bedeutet, dass alle Daten, die direkt oder indirekt zur Unterscheidung der Identität einer Person verwendet werden können (wie z. B. die primäre Kontonummer oder die Adresse), ordnungsgemäß geschützt werden müssen.
Die Hauptaufgabe von OAuth ist es, zu definieren, wie der Kunde eine Autorisierungserlaubnis von einem Ressourcenbesitzer erhalten kann, um auf eine geschützte Ressource zuzugreifen. Ab OAuth 2.0 wurden vier Autorisierungstypen eingeführt: Authorization Code Grant, Implicit Grant, Resource Owner Password Credentials Grant und Client Credentials Grant (D. Hardt, 2012). Die Spezifikation wird normalerweise in Verbindung mit drei Parteien, dem Client, dem Autorisierungsserver und dem Ressourcenbesitzer (Abbildung 1) verwendet, es kann jedoch vorkommen, dass der Client und der Ressourcenbesitzer gleich sind. In solch einem Fall handelt es sich eher um ein 2-stufiges als um ein 3-stufiges OAuth-Protokoll.
Abbildung 1: 3-stufiges OAuth.
Letzteres kann in einer vertrauenswürdigen Umgebung wie B2B oder in einem Cloud-Kontext, in dem sich ein Client beim Autorisierungsserver authentisieren muss, sehr nützlich sein. Obwohl sowohl OAuth 2.0 als auch OAuth 1.0a einen 2-stufigen Ablauf bieten, wird OAuth 2.0 de facto zum vorherrschenden Standard für die API-Authentifizierung bei der Bereitstellung eines Autorisierungsrahmens für verschiedene Clients. Darüber hinaus bildet OAuth 2.0 auch die Basis für OpenID Connect, das organisiert, wie der Identitätsanbieter und der Ressourcenanbieter miteinander kommunizieren (N. Sakimura et al., 2014). Das 2-stufige OAuth 1.0a-Protokoll bringt keine Identitätsinformationen mit, allerdings ist sein Ablauf leicht verständlich, es bietet zusätzliche interessante Sicherheitsaspekte und es ist unkompliziert (M. Atwood et al. 2009). Während der Client Credentials Flow von OAuth 2.0 auf Token (Refresh und Bearer Token) zugreifen muss, bevor eine neue Sitzung gestartet wird, kann OAuth 1.0a in nur einem Schritt verwendet werden, um direkt auf die Ressource zuzugreifen. Abgesehen von einigen einfachen Parametern wie Timestamp oder Nonce muss der Client für OAuth 1.0a im Wesentlichen die digitale Signatur und den Consumer Key (eine statische Kennung, die zum Zeitpunkt der Registrierung beim Provider generiert wurde) an den Server senden. Die Server, auf denen die Ressource gehostet wird, können dann die Authentifizierungs- und Datenintegritätsprüfungen anhand der Signatur und des Consumer Keys durchführen. Diese Funktion macht diese Spezifikation auch für Cloud-Anbieter sehr interessant, bei denen der Verbraucher ausschließlich den Consumer Key und sein eigenes privates PKI-Zertifikat (Private Public Key Infrastructure) sicher speichern muss.
OAuth wurde als Autorisierungsspezifikation konzipiert, obwohl es auch als Authentifizierungsprotokoll in Kontexten verwendet werden könnte, in denen APIs durch Vereinbarungen zwischen Verbraucher und Provider offengelegt werden. Eine Frage, die sich in diesem Zusammenhang stellen kann, lautet: „Warum ist dies wichtig?“ Der Dateneigentümer bestimmt den Grad der Vertraulichkeit der Informationen auf Grundlage unterschiedlicher Finanz-, Regulierungs- oder Datenschutzfaktoren. Der Wert der Daten ist mit Risiken verbunden, die verschiedene Schwachstellen darstellen. Beispielsweise kann die primäre Kontonummer auf einer Kreditkarte als streng vertraulich eingestuft werden. Die Regel lautet: Je höher die Vertraulichkeit und der Datenwert, desto höher sind die Sicherheitsanforderungen im Hinblick auf die Robustheit. Daher kann die Datenklassifizierung Auswirkungen auf die Speicherarchitektur, die angewandten Datenschutzmethoden für gespeicherte und übermittelte Daten sowie auf den Datenzugriff haben (NIST, 2004; NIST, 2013). Da Nutzern das Thema Datensicherheit heutzutage sehr wichtig ist, insbesondere im Hinblick auf die externe Speicherung von Daten, muss eine Sicherheitsrichtlinie entwickelt und umgesetzt werden, um durch starke Authentifizierungsverfahren ein hohes Maß an Datenschutz zu gewährleisten.
In einem OAuth-Kontext ist für Client, Server und Datenübermittlung ein ausreichend starkes Sicherheits-Setup für die Authentifizierung erforderlich, um die Sicherheits- und Datenintegritätskonzepte im Hinblick auf AAA-Systeme (Authentication, Authorization und Accounting) zu gewährleisten. OAuth 1.0a bietet verschiedene Sicherheitsmechanismen für die Authentifizierung: eine HMAC-Signatur mit Shared Secret, eine Plaintext- und eine RSA-Signatur mit PKI. Letztere Option ist besonders für Verbraucher interessant, die die Möglichkeiten von PKI ausschöpfen möchten. In diesem Szenario muss sich der Verbraucher, der die Anmeldeinformationen erhalten möchte, selbst registrieren und seinen eigenen öffentlichen Schlüssel beim Provider hochladen. Mit seinem eigenen privaten Schlüssel, Zertifikat und dem erhaltenen Consumer Key ist der Verbraucher in der Lage, authentifizierte Anfragen zu stellen, die vom Provider verifiziert werden können (Abbildung 2).
Abbildung 2: Überblick des Workflows zur OAuth-Registrierung und Nutzung
Obwohl der Ansatz eines gemeinsamen Schlüssels im Vergleich zum PKI-Ansatz einfacher und weniger komplex erscheinen mag, bietet PKI Cloud-Anbietern aufgrund der Schlüsselgenerierung eine gute Möglichkeit, selbstregistrierende Portale anzubieten, über die Kunden ihre öffentlichen X509-Schlüssel hochladen können, um einen zentralen Punkt zur Überwachung und Umsetzung zu erhalten.
Hinter der Entwicklung von OAuth stehen Anforderungen aus Social-Media-Anwendungen, bei denen die Nutzer von der Mühsal der Passworterstellung befreit wurden. Auch Enterprise-Unternehmen erkannten die Vorteile von OAuth und begannen, diesen Standard in ihre Identity-Management-Lösung einzubinden. Im Hinblick auf die Nutzung von Bearer Token vs. Digital Signature bleibt die Debatte zwischen OAuth 2.0 und OAuth 1.0a weiter offen (hueniverse, 2016). Im Gegensatz zu einem Autorisierungskontext, für den OAuth entwickelt wurde, ist die Verwendung von OAuth in einem Authentifizierungskontext also ein sensibles Thema. Aus Einfachheits- und Sicherheitsgründen lohnt es sich daher, die 2-stufige Option von OAuth 1.0a für eine starke Authentifizierung im B2B-Kontext in Betracht zu ziehen.
Referenzen:
D. Hardt, 2012. The OAuth 2.0 Authorization Framework. [ONLINE] Available at: https://tools.ietf.org/html/rfc6749. [Accessed 13 May 2016].
C. Eric, P.Yutong, C. Shuo, T. Yuan, K. Robertand T. Patrick, 2014 OAuth Demystified for Mobile Application Developers. [ONLINE] Available at: http://research.microsoft.com/pubs/231728/OAuthDemystified.pdf. [Accessed 20 May 2016].
N. Sakimura et Al., 2014. OpenID Connect Core 1.0. [ONLINE] Available at: http://openid.net/specs/openid-connect-core-1_0.html. [Accessed 13 May 2016
M. Atwood et Al., 2009. The OAuth 2.0 Authorization Framework. [ONLINE] Available at: http://oauth.net/core/1.0a/. [Accessed 13 May 2016].
NIST, 2004. Standards for Security Categorization of Federal Information and Information Systems. [ONLINE] Available at: http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf. [Accessed 13 May 2016].
NIST, 2013. Electronic Authentication Guideline. [ONLINE] Available at: http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf. [Accessed 13 May 2016].
hueniverse, 2016. OAuth 2.0 and the Road to Hell | hueniverse. [ONLINE] Available at: https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/. [Accessed 20 May 2016].