© Krol/Shutterstock.com
ASP.NET Web API: Sicherheit durch OAuth 2.0 und JWT

Auf Nummer sicher gehen


Web-APIs als zentrale Ressourcenzugriffspunkte erfreuen sich aufgrund ihrer positiven Eigenschaften zunehmender Beliebtheit. Das gilt sowohl für öffentliche Schnittstellen als auch für im Enterprise-Umfeld genutzte APIs. Doch mit zunehmender Verbreitung spielt auch das Thema Sicherheit eine immer größere Rolle. Der Artikel zeigt, welche Vor- bzw. Nachteile unterschiedliche Authentifizierungsverfahren bieten und wie sich ASP.NET Web API mittels eines eigenen Identitätsanbieters unter der Verwendung von OAuth und JWT gegen unbefugte Zugriffe absichern lässt.

Eigentlich ist das Thema Authentifizierung so alt wie das HTTP-Protokoll selbst. Doch die damit verbundenen Herausforderungen haben sich bis heute nicht geändert. Der Hauptgrund hierfür liegt in der statuslosen Natur des HTTP-Protokolls. Im Klartext bedeutet das: Meldet sich ein Benutzer mit seinen Zugangsdaten an einem Webserver an, so kann diese Anfrage authentifiziert werden. Der nächste Aufruf wäre jedoch wieder anonym, da eben keine permanente Verbindung zwischen Server und Client besteht. Es sei denn, es kommt zu einer erneuten Übermittlung der Benutzerinformationen.

Basic Authentication

Um sich diesem Problem zu stellen, erfand man die Basic Authentication – den einfachsten Weg, sich gegenüber einer Webapplikation zu authentifizieren. Dieses Verfahren basiert auf einem Challenge-Response-Modell und verwendet Standard-HTTP-Header zur Flusssteuerung. Vereinfacht dargestellt, fragt ein Client eine Website an, die eine Authentifizierung erfordert. Die Website liefert dann den HTTP-Statuscode 401 zurück sowie weitere Headerinformationen für die benötigten Authentifizierungsverfahren.

HTTP/1.1 401 Access Denied WWW-Authenticate: Basic realm="localhost" Content-Length: 0

Erhält der Browser die Antwort vom Webserver, öffnet sich in der Regel eine Eingabemaske, in die der Benutzername und das Passwort einzutragen sind. Benutzername und Passwort, getrennt durch einen Doppelpunkt, werden dann als Base64-encodierter String mittels des HTTP-Authorization-Headers an den Webserver übermittelt. Damit der Server weiß, um welchen Authentifizierungstyp es sich handelt, wird dem encodierten String Basic vorangestellt. Verläuft die Authentifizierung erfolgreich, werden die angeforderten Inhalte an den Client ausgeliefert.

GET /index.html HTTP/1.1 Host: localhost Authorization: Basic S2V2aW46V2llc2JhZGVu

Der Vorteil dieses Verfahrens liegt vor allem darin, dass weder Cookies noch Sessions benötigt werden. Des Weiteren bedarf es auch keiner speziellen Log-in-Seite, da der Browser die Maske zur Eingabe der Authentifizierungsinformationen bereitstellt. Diesen Vorteilen steht jedoch eine Reihe von Nachteilen gegenüber. Das Hauptproblem ist die permanente Übertragung von Benutzername und Passwort im Klartext. Da diese Übertragung bei jedem Seiten- bzw. Serviceaufruf erfolgt, bieten sich für Angreifer hervorragende Chancen, an diese sensiblen Daten zu gelangen (z. B. durch eine Man-in-the-Middle-Attacke). Eine sichere HTTPS-Verbindung bei der Verwendung von Basic Authentication ist also unabdingbar. Um zu verhindern, dass der Benutzer seine Anmeldeinformationen bei jedem Aufruf eingeben muss, speichert der Browser diese Informationen zwischen. Eigentlich ein nettes Komfortfeature. Je nach Browser hat sich diese Funktion jedoch schon das ein oder andere Mal als Fallstrick erwiesen. Ändert der Benutzer beispielsweise sein Passwort auf der Webseite, bekommt der Browser nichts davon mit und übermittelt beim Aufruf falsche Credentials. Auch der Server hat keine Möglichkeit, den Benutzer abzumelden. Das führt dann dazu, dass die Website nicht mehr ausgeliefert wird und der Benutzer die Fehlermeldung „Zugriff verweigert“ erhält.

Integrierte Windows-Authentifizierung

Trotz der aufgeführten Nachteile findet man diese Authentifizierungsvariante doch relativ häufig im Enterprise-Umfeld. Eine Alternative zur Basic Authentication bildet die integrierte Windows-Authentifizierung. Oftmals kommt diese (schon etwas in die Jahre gekommene) Technologie bei unternehmensinternen Webapplikationen (Intranet, Reisekostentools, Zeiterfassungslösungen etc.) zum Einsatz, da sie Benutzern unter der Verwendung von NTLM oder Kerberos ein Single Sign-on ermöglicht. Somit muss sich ein Benutzer nur einmalig an Windows anmelden und kann kompatible Weblösungen anschließend nutzen, ohne sich erneut authentifizieren zu müssen.

Im Internet anzutreffende Authentifizierungsverfahren basieren häufig auf einem serverbasierten Modell und nutzen meist Cookies zur Identifikation des Clients. Doch auch diese Variante bietet neben ihren Vorteilen auch einige Nachteile, zum Beispiel bei der Skalierbarkeit. Jedes Mal, wenn sich ein Benutzer am Server anmeldet, muss das irgendwo vermerkt werden. Meist wird hierzu ein Eintrag im Speicher oder in einer Datenbank angelegt. Je nach verfügbaren Ressourcen kann dies somit der Flaschenhals einer Applikation sein. Sollen Services von anderen Webapplikationen konsumiert werden, stößt man schnell auf das CORS-Problem (Cross-Origin Resource Sharing). Denn die Same-Origin Policy (SOP) verbietet den domainübergreifenden Zugriff auf Ressourcen mittels Ajax Call aus Sicherheitsgründen. Auch wenn es Möglichkeiten gibt, diese Probleme zu umgehen, beispielsweise durch JSONP oder den Access-Control-Allow-Origin-Header, handelt es sich meist um keine wirklichen Komfortlösungen.

Ein weiteres Problem stellen die auf dem Client gespeicherten Cookies dar. Denn auch sie lassen sich über Cookie oder Session Hijacking stehlen, um dann die Sitzung eines angemeldeten Benutzers übernehmen zu können. Neben den aufgeführten Nachteilen aller Verfahren haben diese noch ein weiteres Manko: Sie sind ausschließlich für die Authentifizierung im Web geeignet. Sollen aber nun Services von einer App, wie sie auf Smartphones, Tablets, Smart-TV-Geräten, Blu-ray-Playern usw. zu finden sind, genutzt werden, ist das entweder gar nicht oder nur mit vergleichsweise hohem Aufwand möglich. Abhilfe schaffen tokenbasierte Authentifizierungsverfahren, die in der Regel einem einfachen Schema folgen:

  • Beim Anmeldeprozess wird mittels Benutzername und Passwort ein gültiges Token von einem entsprechenden Endpunkt angefordert.

  • Die Applikation überprüft die Benutzeranmelde­informationen.

  • Sind die Credentials valide, stellt die Applikation ein signiertes Token für den Benutzer aus und sendet es zurück an den Client.

  • Das Token wird auf dem Client zwischengespeichert.

  • Bei jeder Anfrage wird das Token nun übermittelt und vom Server (bzw. von der Applikation) validiert.

  • Ist das Token valide, liefert der Webserver die angefragten Inhalte aus.

Doch was sind die Vorteile dieses Verfahrens? Es kommen keine webtechnologiespezifischen Artefakte, wie zum Beispiel Cookies, zum Einsatz. Der Client erhält stattdessen ein Token, bei dem es sich um eine Textzeichenfolge handelt. Darüber hinaus kann der Entwickler entscheiden, wo und wie das Token auf dem Client gespeichert wird. Handelt es sich beispielsweise um eine Webapplikation, kann der Local Storage bzw. Session Storage genutzt werden. In einer mobilen App hingegen stehen andere Möglichkeiten der Persistierung zur Verfügung. Skalierungsprobleme, wie sie bei Session-basierten Verfahren auftreten können, entfallen auf...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang