Beim Vergleich verschiedener Authentifizierungsschemata wie HTTP Basic Authentication vs. HTTP Digest Access Authentication, One-Way SSL vs. Two-Way SSL, SAML vs. WSS oder OAuth 1.0 vs. OAuth 2.0 stellt man fest, dass sie alle ähnliche Probleme beschreiben, wenn es um die Anwendung von Signaturen zur Umsetzung der bekannten AAA-Anforderungen geht. Die Art wie und wo digitale Signaturen angewendet werden, insbesondere auf neue Authentifizierungsprotokolle wie OAuth, kann allerdings neue und interessante Szenarien zum Schutz von APIs anbieten.
Die zahlreichen Rückmeldungen zum Blog «Authentifizierung vs. Autorisierung mit OAuth» (Knupfer Rainer, Bricalli Cristina. 2016) zeigen, dass wir vielleicht zu viel auf einmal wollten. Wir haben verschiedene OAuth-Spezifikationsversionen eingeführt, Bearer Token und Signaturen beschrieben, die Vor- und Nachteile von PKI vs. Shared Key erörtert und eine Gesamtarchitektur eines selbstregistrierenden Portals entworfen. Ganz schön viel auf einmal! Wir haben uns sehr gefreut, dass die Notwendigkeit einer starken Authentifizierung nachvollziehbar war, wenn vertrauliche Informationen weitergeleitet werden. Wir sind allerdings der Meinung, dass wir noch einen Schritt weiter gehen müssen, um verschiedene Aspekte in Bezug auf Signaturen und Tokentyp im Kontext von OAuth zu erklären, da diese noch nicht so richtig klar zu sein scheinen.
Technische Architekten und Software Engineers müssen sich oft mit vielen kleinen Details, verschiedenen Architekturtypen, technischen Spezifikationen und neuen Trends auseinandersetzen und so kann es vorkommen, dass «subtile» Unterschiede (wie das Signieren von Anfrage und Token) erst zu einem späteren Zeitpunkt offensichtlich werden. Während eine signierte Anfrage die Kommunikation zwischen zwei Parteien sichert, werden signierte Token zum Schutz der Tokenintegrität verwendet und sind notwendig, um eine vertrauenswürdige Beziehung zwischen Autorisierungsserver und der geschützten Ressource herzustellen.
(Quelle: Understanding Trust-Direction. 2016)
Im Hinblick auf den vorherigen Blogbeitrag fällt die 2-stufige OAuth 1.0a-Nutzung in die Kategorie des Schutzes einer Anfrage. Als «Nebeneffekt» haben wir ausserdem eine starke Authentifizierung erreicht. Abgesehen von der Tatsache, dass die OAuth-Spezifikation ursprünglich entwickelt wurde, um unsichere Kommunikationen zu schützen, bestand das erklärte Ziel eigentlich in der Erstellung eines Protokolls der delegierten Autorisierung (hueniverse 2016). In diesem Delegationsprozess ist das für den Zugriff auf die geschützte Ressource erhaltene Token der wichtigste Faktor.
Im Kontext des Tokens, das mit der OAuth2.0-Spezifikation verwendet wird, finden wir das Bearer Token Profile (RFC 6750, 2016) sowie das Message Authentication Code (MAC) Token Profile (OAuth 2.0 Message Authentication Code (MAC) Tokens. 2016) vor. Der Vergleich von Bearer Token mit MAC Token ist wie der Vergleich von Bargeld mit Kreditkarten. Während erstere von jedermann ohne Legitimation verwendet werden können, müssen MAC Token zuerst signiert werden, um danach verwendet und validiert werden zu können. Tatsächlich definiert die MAC Token-Spezifikation, wie Clients die vom Dienstleister geforderte OAuth 2.0-Anforderung signieren müssen. Das Bearer Token muss in einer vertrauenswürdigen Umgebung mit einem sicheren HTTPS-Kommunikationskanal verwendet werden. Im Gegensatz dazu können MAC Token in verschiedenen Szenarien verwendet werden. Beispiele dafür sind: der Integritätsschutz über unsichere Kanäle, die Point-to-Point Encryption (P2PE) oder die End-to-End Encryption (E2EE) über mehrere Hops. Ähnlich einer signierten Anfrage bietet ein signiertes Token den Vorteil eines Authentifizierungs- und Nichtabstreitbarkeits-Mechanismus.
Die Idee hinter einem MAC ist es, eine Nachricht zu erzeugen, die ohne den geheimen Schlüssel nicht erstellt werden kann. HMAC integriert eine Hash-Nachricht und den Schlüssel mittels eines HMAC-SHA1- oder HMAC-SHA256-Algorithmus (Krawczyk et al., 1997), so dass der Empfänger die Integrität und Authentizität überprüfen kann.
Nachrichten-Authentifizierungscode (Quelle: Wikipedia. 2016)
Das Gute an dieser Methode ist, dass keine komplexe PKI-Infrastruktur erforderlich ist, und dass verschiedene Aspekte der X509-Zertifikate (wie Zertifikatsautorität und Vertrauenskette) nicht berücksichtigt werden müssen. Wie bei jeder symmetrischen Verschlüsselungslösung müssen sich die Parteien mit der Schlüsselverteilung und dem Schutz von geheimen Schlüsseln auseinandersetzen. OAuth 2.0 ist hauptsächlich ein 3-stufiges Protokoll, das mit der zuvor ausgetauschten Autorisierungserlaubnis für ein Zugriffstoken auf die geschützte Ressource zugreift und so das Token zur Berechnung des MAC verwendet.
Um die Anfrage zu validieren, definiert das OAuth 2.0 MAC Token Profile den mac_key, einen Session Key, der als Schlüssel zum Signieren verwendet wird, und den verschlüsselten Shared Key, der in das access_token eingebettet ist. Natürlich verwendet dieses Profil Nonce und Timestamp, um Wiederholungsangriffe zu erkennen und einzudämmen, allerdings beschreibt dies in etwa, wie das Geheimnis bei diesem Profil ausgetauscht wird.
Sind Sie nach dem Lesen dieser beiden Blogeinträge etwas verwirrt? Ist es nicht widersprüchlich, einmal das 2-stufige OAuth 1.0a-Schema mit PKI-Infrastruktur zu empfehlen und ein anderes Mal das 3-stufige OAuth 2.0-Schema mit symmetrischer Verschlüsselung vorzuschlagen? Ein Berater würde antworten, ja, aber es kommt auf die Umstände an ... Tatsächlich ist der Schutz der API keine triviale Angelegenheit, die ohne jeden Zweifel gelöst werden kann. Der beste Ansatz wäre, die beiden Spezifikationen technisch zu vergleichen und die richtigen Einsatzbereiche zu bestimmen, aber dies ist hier nicht das Thema. Der Einfachheit halber können wir annehmen, dass OAuth 1.0a zweifelsohne ein sicheres signaturbasiertes Protokoll ist, das erfolgreich in Unternehmensumgebungen verwendet wird. Auch wenn OAuth 2.0 eine Evolution zu sein scheint, handelt es sich in Wahrheit um einen anderen Sicherheitsansatz. Momentan verwenden Unternehmensumgebungen mit eingerichteten Sicherheitsgateways noch immer OAuth 1.0a, während OAuth 2.0 hauptsächlich in sozialen Netzwerken verwendet wird, in denen die Sicherheitsanforderungen moderater sind. Das MAC Token Profile ist komplexer und so für den Client und den Ressourcenserver schwieriger zu implementieren. Darüber hinaus ist der Ansatz noch nicht ausgereift und dadurch in der IT-Branche noch nicht weit verbreitet.
Referenzen
hueniverse. 2016. Beginner’s Guide to OAuth – Part III : Security Architecture | hueniverse. [ONLINE] Available at: https://hueniverse.com/2008/10/03/beginners-guide-to-oauth-part-iii-security-architecture/. [Accessed 13 September 2016].
RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage. 2016. RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage. [ONLINE] Available at: https://tools.ietf.org/html/rfc6750. [Accessed 13 September 2016].
draft-ietf-oauth-v2-http-mac-05 - OAuth 2.0 Message Authentication Code (MAC) Tokens. 2016. draft-ietf-oauth-v2-http-mac-05 - OAuth 2.0 Message Authentication Code (MAC) Tokens. [ONLINE] Available at: https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05. [Accessed 13 September 2016].
Krawczyk, Bellare, Canetti. 1997. HMAC: Keyed-Hashing for Message Authentication. [ONLINE] Available at: https://www.ietf.org/rfc/rfc2104.txt. [Accessed 14 September 2016].
Knupfer Rainer, Bricalli Cristina. 2016. Authentication vs. Authorization with OAuth, Does It Really Matter?, Available here (Accessed: 16th September 2016).
Understanding Trust Direction. 2016. Understanding Trust Direction. [ONLINE] Available at: https://technet.microsoft.com/en-us/library/cc731404(v=ws.11).aspx. [Accessed 27 September 2016].
Wikipedia. 2016. Message authentication code - Wikipedia, the free encyclopedia. [ONLINE] Available at: https://en.wikipedia.org/wiki/Message_authentication_code. [Accessed 27 September 2016].