Externe Authentifizierung mit OAuth 2 und ASP.NET Web API – Teil 1

Ich arbeite gerade an einem kleinen Dienst, der auf der Serverseite die ASP.NET Web API und clientseitig JavaScript im Browser verwendet. Da es für Benutzer möglichst einfach sein soll, sich für den Dienst anzumelden, kann man dies mit einem bestehenden Facebook, Twitter oder Microsoft Account tun. Mit der Vorlage für ein ASP.NET Web API Projekt in Visual Studio ist das Ganze in wenigen Minuten eingerichtet und funktioniert wunderbar.

Doch dann kam die Anforderung, dass man den Dienst auch über eine Windows Phone App verwenden können soll. Und natürlich soll es auch da dem Benutzer möglich sein, sich mit dem Anbieter seiner Wahl zu authentifizieren. Leider gibt es dafür keine Vorlage, mit der das in wenigen Minuten erledigt ist, sondern man muss schon selber etwas Code schreiben. Bislang habe ich mir noch recht wenig Gedanken darüber gemacht, wie denn dieses OAuth Protokoll eigentlich funktioniert. Daher habe ich diese Anforderung als willkommenen Anlass genommen, um diesen Umstand zu ändern.

In 3 Beiträgen möchte ich euch nun kurz über meine Erkenntnisse berichten. Dieser erste Teil gibt einen groben Überblick über das OAuth Protokoll im Allgemeinen. Im zweiten Teil zeige ich anhand eines Beispiels, was denn im Hintergrund so alles passiert, wenn sich ein Benutzer mit Facebook anmeldet. Und im letzten Teil gibt es dann noch die Auflösung, wie man das Ganze in einer Windows Phone App verwenden kann.

Na dann legen wir mal los…

OAuth 2.0

Das OAuth 2.0 Protokoll ist ein offener Standard, der von der Internet Engineering Task Force entwickelt und von sehr vielen großen Anbietern von Internetdiensten unterstützt wird. Dazu zählen namhafte Unternehmen wie Facebook, Twitter, Microsoft und Google. Die genauen Spezifikationen findet man im RFC 6749.

Rollen

Die OAuth Spezifikation beschreibt die folgenden vier Rollen:

• Resource Owner
  Ist eine Instanz (z.B. ein Benutzer) der Zugriff auf eine geschützte Ressource geben kann.
• Resource Server
  Der Server, auf dem die geschützte Ressource gespeichert ist.
• Client
  Eine Anwendung, die im Auftrag und mit den Rechten des Resource Owners auf eine geschützte Ressource zugreift.
• Authorization Server
  Dieser Server stellt Access Tokens aus, nachdem der Resource Owner sich erfolgreich authentifiziert hat.

Authorization Grant

Unter Authorization Grant versteht man den Berechtigungsnachweis des Resource Owners, den der Client verwendet, um einen Access Token anzufordern. Das OAuth Protokoll beschreibt vier verschiedene Grant Types, kann aber auch um zusätzliche erweitert werden.

• Authorization Code
  Anstatt die Zugangsdaten vom Resource Owner abzufragen, leitet der Client bei dieser Methode den Resource Owner auf den Authorization Server weiter. Nachdem sich der Resource Owner angemeldet hat, wird er samt Authorization Code wieder zurück zum Client umgeleitet.
  Der Client kommt dadurch nie in den Besitz der Zugangsdaten. Durch die Verwendung des Authorization Codes, mit dem der Client einen Access Token beim Authorization Server anfordert, muss der Access Token nicht über den User-Agent übertragen werden.
• Implicit
  Dies ist eine vereinfachte Variante der Authorization Code Methode, die speziell für Clients im Browser (z.B. mit JavaScript) entwickelt wurde. Anstatt des Authorization Code wird gleich ein Access Token an den Client übergeben.
• Resource Owner Password Credentials
  Bei dieser Methode fordert der Client einen Access Token direkt mit den Zugangsdaten des Resource Owner an. Das bedeutet jedoch, dass der Client in Besitz dieser Zugangsdaten kommt.
• Client Credentials
  Der Client verwendet seine eigenen Zugangsdaten (Client ist Resource Owner) um einen Access Token anzufordern.

Ablauf unter Verwendung des Authorization Code Grant

Die Verwendung des Authorization Code Grants ist die bevorzugte Variante für die Authentifizierung über einen externen Anbieter. Wie bereits vorhin beschrieben, kommt der Client dabei nie in Besitz der Zugangsdaten des Resource Owners und der Access Token wird nicht über den User-Agent übertragen. Die folgende Grafik zeigt den gesamten Ablauf unter Verwendung des Authorization Code Grants.

1. Der Benutzer surft die Webanwendung (Client) an.
2. Dieser leitet den User-Agent des Benutzers auf die Anmeldeseite des externen Anbieters (Authorization Server) um.
3. Der Benutzer gibt seine Zugangsdaten in das Anmelde-Form ein und schickt die Daten ab.
4. Wenn die Zugangsdaten korrekt sind, wird der User-Agent wieder zurück an den Client umgeleitet.
5. Über den User-Agent übergibt der Authorization Server dabei einen einmal-verwendbaren Authorization Code an den Client.
6. Mit diesem Authorization Code, seiner eigenen ID und seinem Client Secret fordert der Client beim AS einen Access Token an.
7. Der AS überprüft die Daten und stellt dem Client einen Access Token aus.
8. Der Client verwendet den Access Token, um Benutzerinformationen vom AS anzufordern.
9. Sofern der Client berechtigt ist, auf die angeforderten Daten zuzugreifen, werden die Informationen an den Client gesendet.

OAuth und Web API

Die ASP.NET Web API setzt seit Version 2 auf OWIN, dem Open Web Interface für .NET, auf. Dabei handelt es sich um eine Schnittstelle zwischen Server und Anwendung, die diese zwei Komponenten entkoppeln soll. Die Implementierung für Microsoft Server und Komponenten wird von Microsoft unter dem Namen Katana entwickelt und steht auf Codeplex als Open Source Projekt zur Verfügung.

Auch der gesamte Authentifizierungsvorgang wird nun über die OWIN Schnittstelle durchgeführt. Im Katana Projekt befinden sich daher zahlreiche Implementierungen von verschiedenen Authentifizierungsmechanismen, die alle in einem Web API Projekt verwendet werden können. Da der OAuth Standard in der Implementierung einen gewissen Spielraum lässt, sind auch vorkonfigurierte Schnittstellen für die gängigsten Provider vorhanden. Eine gute Anleitung, wie man die verschiedenen Anbieter für die Verwendung in einer Single Page Application konfiguriert, findet man auf der ASP.NET Seite von Microsoft.

Das Visual Studio Template für eine Single Page Application erzeugt einen eigenen AccountController, der für das Registrieren und Anmelden von Benutzern verwendet wird. Welche Methoden darin für die externe Authentifizerung verwendet werden und wie der gesamte Ablauf aussieht, wenn sich ein Benutzer über Facebook anmeldet, lest ihr im nächsten Teil.