Innovation

Soziale Authentifizierung in ASP.NET MVC 4

Dino Esposito

Meiner Einschätzung nach werden in Zukunft die meisten Websites, die Benutzer authentifizieren müssen, soziale Authentifizierungsgateways einsetzen. In diesem Zusammenhang bildet ein soziales Authentifizierungsgateway einfach die Authentifizierungsplattform, die von bekannten sozialen Netzwerken wie Twitter und Facebook öffentlich zur Verfügung gestellt wird. Wenn Sie an den Anfang von ASP.NET zurückdenken, werden Sie sicherlich Ähnlichkeiten zwischen dem Konzept der Passport-Initiative und dem der heutigen sozialen Authentifizierungsgateways feststellen. Natürlich gibt es Unterschiede. Beide Szenarien zeichnen sich jedoch dadurch aus, dass die Benutzerfreundlichkeit verbessert werden soll, indem die Anzahl sich zu merkender Anmeldeinformationen reduziert wird.

Das Wiederverwenden von Anmeldeinformationen hat Vor- und Nachteile. Auf der einen Seite wird die Sicherheitsbarriere für Ihre persönlichen Daten gesenkt. Indem Sie immer den gleichen Benutzernamen und das gleiche Kennwort verwenden, erhalten Hacker mehr Zeit, Ihre Geheimnisse zu erraten. Wenn Sie einmal gehackt wurden, ist zudem der Umfang der vom Angriff betroffenen Daten größer. Auf der anderen Seite ist es jedoch viel einfacher, eine Verbindung zu neuen Diensten herzustellen und diese zu testen, wenn Sie immer die gleichen Anmeldeinformationen verwenden. Dienstbesitzer sehen dies positiv, weil dadurch die Anzahl von Benutzern schneller ansteigt und die Entwicklung ihres Diensts erfolgreicher verläuft.

Kurz gesagt, immer mehr Websites, die eine große Benutzerbasis aufbauen möchten, bieten heutzutage zwei Optionen zur Registrierung an: entweder mithilfe Ihrer eigenen Anmeldeinformationen oder über ein Authentifizierungsgateway eines sozialen Netzwerks. Dieser Trend ist so attraktiv, dass in der neuesten Version von ASP.NET MVC 4 ein Ad-hoc-Framework zum Authentifizieren von Benutzern über eine Vielzahl sozialer Netzwerke enthalten ist. In diesem Artikel werde ich den Code besprechen, der sich in der Projektvorlage von ASP.NET MVC 4 befindet. Soziale Authentifizierungsgateways verwenden das Open Authentication(OAuth)-Protokoll, das sich als ein sehr ausführliches Protokoll herausstellt. Daher ist der resultierende Code nicht unbedingt trivial und macht möglicherweise weitere Erklärungen notwendig.

Der schnellste Weg zur MVC-Authentifizierung

Mit ASP.NET MVC können Sie mit dem Codieren in einer Codevorlage beginnen, die bereits Authentifizierung umfasst. Die mit ASP.NET MVC 4 gelieferte Internet Application-Vorlage erweitert die Unterstützung für soziale Gateways. Nehmen wir einmal an, Sie stehen vor einem ganz neuen Internet Application-Projekt. Bei der ersten Codeerstellung kommt es zu keinen besonderen Vorfällen. Auf der Seite in Abbildung 1 werden Sie informiert, dass noch kein externer Authentifizierungsdienst aktiviert wurde.

Abbildung 1: Die ASP.NET MVC 4-Vorlage ohne Konfiguration eines externen Authentifizierungsdiensts

Sie können einen beliebigen der unterstützten Dienste aktivieren, indem Sie ein paar kleine Änderungen an der Codebehind-Datei „global.asax“ vornehmen. Es empfiehlt sich in ASP.NET MVC 4, Projekten einen App_Start-Ordner mit xxxConfig-Klassen hinzuzufügen, die Initialisierungsaufgaben ausführen. Derartige Klassen sind schlichte Container statischer Methoden, die den Bootstrappercode der Anwendung besser organisieren. Hier ist eine Momentaufnahme:

protected void Application_Start()
{  ...  AuthConfig.RegisterAuth();}

Die RegisterAuth-Methode enthält den Code, mit dem sich Benutzer von anderen Websites wie Facebook und Twitter mit ihren Konten anmelden können:

public static class AuthConfig
{
public static void RegisterAuth()
  {
    OAuthWebSecurity.RegisterTwitterClient(
      consumerKey: yourTwitterAppKey
      consumerSecret: yourTwitterAppSecret);
    OAuthWebSecurity.RegisterFacebookClient(
      appId: yourFacebookAppKey,
    appSecret: yourFacebookAppSecret);
  }
}

Die OAuthWebSecurity-Klasse stammt aus dem Webseitenframework und befindet sich im Microsoft.Web.WebPages.OAuth-Namespace. In dieser Klasse sind die Kernfunktionen des OAuth-Protokolls zusammengefasst, wie sie in der DotNetOpenAuth(DNOA)-Bibliothek implementiert sind (siehe dotnetopenauth.net).

Um Benutzer bei einem sozialen Netzwerk zu authentifizieren, müssen Sie zuerst im sozialen Netzwerk eine Anwendung erstellen. Folglich benötigen Sie eine Twitter- sowie eine Facebook-Anwendung, um Benutzer von Ihrer Website über Twitter und Facebook zu authentifizieren. Die von Ihnen erstellte Twitter-/Facebook-Anwendung hat wahrscheinlich den gleichen Namen wie Ihre Website und ist so konfiguriert, dass sie mit der Website verknüpft ist. Bei der hier als Twitter-/Facebook-Anwendung bezeichneten Anwendung handelt es sich nicht wirklich um eine vollständige Anwendung. Sie besitzt zudem ein spezielles Entwicklertoken für einen programmgesteuerten Zugriff auf Twitter, Facebook und weitere soziale Netzwerke. In vorangegangenen Ausgaben dieser Rubrik zur Facebook-Programmierung habe ich diesen Aspekt bereits ausführlich behandelt. Im Rahmen dieses Artikels besteht eine Twitter-/Facebook-Anwendung aus einem Paar von Zeichenfolgen: eine Zeichenfolge ist als Schlüssel und die andere ist als Geheimnis bekannt. Der Schlüssel und das Geheimnis sind eindeutig mit der sozialen Anwendung verknüpft. Sie initialisieren „OAuthWebSecurity“, indem Sie den Schlüssel und das Geheimnis für jedes soziale Netzwerk, das Sie unterstützen möchten, übergeben.

Indem Sie einfach Aufrufe von „RegisterTwitterClient“ und „RegisterFacebookClient“ hinzufügen, werden auf der Benutzeroberfläche des Beispielprojekts nun diese Registrierungsoptionen als Schaltflächen angezeigt. Wenn sich Benutzer anmelden möchten (über die Schaltfläche „Log in“), werden sie zur Twitter-/Facebook-Website umgeleitet, wo sie die Authentifizierung fortsetzen können. Wenn alles ordnungsgemäß funktioniert, werden sie anschließend zur ursprünglichen Website weitergeleitet und von ASP.NET als authentifizierte Benutzer erkannt.

Das klingt ziemlich unkompliziert, nicht wahr? Nun, hinter den Kulissen muss eine Vielzahl an Einzelheiten beachtet werden.

Der OAuth-Weg zur Authentifizierung

Wenn der Benutzer auf die Twitter-Schaltfläche klickt, erfolgt eine Navigation zu „Account/ExternalLogin“. Sehen wir uns den Code für die Methode an (er befindet sich in der AccountController.cs-Datei):

public ActionResult ExternalLogin(String provider, 
  String returnUrl)
{
  return new ExternalLoginResult(provider,
    Url.Action("ExternalLoginCallback",
    new { ReturnUrl = returnUrl }));
}

Die ExternalLoginResult-Klasse fasst auf eine Art den folgenden Code zusammen, mit dem eigentlich das Authentifizierungsgateway kontaktiert wird:

OAuthWebSecurity.RequestAuthentication(Provider, ReturnUrl);

Die ExternalLoginResult-Klasse ist eine Hilfsklasse, die sich auch in der Datei „AccountController.cs“ befindet. Anhand des name-Attributs der Schaltfläche können Sie erkennen, dass im Projektvorlagencode der Name des Anbieters aufgelöst wird:

    <button type="submit"
      name="provider"
      value="@p.AuthenticationClient.ProviderName"
      title="Log in using your @p.DisplayName account">
      @p.DisplayName
    </button>

Letzten Endes empfängt die RequestAuthentication-Methode den Namen des Authentifizierungsanbieters (Twitter, Facebook oder ein anderer unterstützter Anbieter) und die zurückzugebende URL. Standardmäßig unterstützt „OAuthWebSecurity“ die folgenden Anbieter: Twitter, Facebook, LinkedIn, Google, Microsoft und Yahoo. Intern führt die Methode die Aufgabe mithilfe der DNOA-Bibliothek aus. Im Folgenden wollen wir uns ansehen, was passiert, wenn der Benutzer die Authentifizierung über Twitter wählt.

Als Erstes wird die standardmäßige Twitter-Authentifizierungsseite angezeigt. Sie enthält den Namen der Twitter-Anwendung, mit der die Aufgabe durchgeführt wird. In dem in Abbildung 3 aufgeführten Beispiel heißt sie „tFun“. Wenn Sie eine Twitter-Anwendung konfigurieren, geben Sie auch die Berechtigungen an, die der Benutzer der Anwendung bei der Anmeldung erteilen muss. Durch die ordnungsgemäße Konfiguration der sozialen Anwendung können Sie der ASP.NET-Website die Berechtigung erteilen, neue Benutzer zu verfolgen oder Beiträge im Namen des verbundenen Benutzers zu veröffentlichen. Dies gilt nicht für die Beispielanwendung. 

Abbildung 2: Authentifizierung über Twitter

Wenn der Benutzer Anmeldedaten eingibt, die von Twitter (oder dem gewünschten sozialen Netzwerk) als gültig anerkannt werden, findet eine Umleitung zurück zur angegebenen Rückgabe-URL statt. Die nächste Methode, mit der Sie die Kontrolle über die Authentifizierung hinaus zurückerhalten, heißt „ExternalLoginCallback“. Zu diesem Zeitpunkt wissen Sie nur, dass der Benutzer, der auf Ihre Anwendung zugreifen möchte, erfolgreich als Twitter-Benutzer erkannt wurde. Sie haben ansonsten keine Informationen und kennen noch nicht einmal den Benutzernamen. Ich kann mir kaum eine Anwendung vorstellen, die authentifizierte Benutzer erfordert und Benutzernamen oder E-Mail-Adressen einfach ignorieren kann. Nach der Authentifizierung empfängt die Anwendung nur einen Code, wurde aber noch nicht autorisiert, programmgesteuert auf die Twitter-API zuzugreifen. Hierfür muss der zu diesem Zeitpunkt empfangene Code gegen ein Zugriffstoken ausgetauscht werden (das in der Regel zeitlich begrenzt ist, um Missbrauch zu verhindern). Zu diesem Zweck wird die VerifyAuthentication-Methode im Textkörper von „ExternalLoginCallback“ aufgerufen. Das AuthenticationResult-Objekt, das von „VerifyAuthentication“ zurückgegeben wird, enthält einige Informationen über den Benutzer. Die tatsächlichen Informationen, die Sie erhalten, können je nach Anbieter möglicherweise leicht voneinander abweichen .Der Benutzername ist jedoch normalerweise zumindest enthalten.

Von der Authentifizierung zur Mitgliedschaft

Die Authentifizierung eines Benutzers ist nur der erste Schritt. Als Nächstes müssen Sie den Benutzer anhand des Namens innerhalb der Website nachverfolgen. In einem klassischen ASP.NET-Mitgliedschaftssystem wird zuerst ein Anmeldeformular angezeigt, Anmeldeinformationen werden überprüft, und dann wird ein Authentifizierungscookie mit dem Benutzernamen erstellt. Optional werden zusätzlich weitere Schlüsselinformationen erstellt. Twitter oder Facebook ersparen Ihnen den Aufwand, Anmeldeformulare einzurichten und Anmeldeinformationen zu überprüfen. Außerdem müssen Sie sich um die nicht unbedeutende Belastung des Speicherns und Verwaltens von Konten mit vertraulichen Informationen wie Kennwörtern nicht kümmern.

Grundsätzlich benötigt jedoch fast jede Anwendung, die authentifizierte Benutzer erfordert, auch ein Mitgliedschaftssystem, in dem jeder regelmäßige Benutzer anhand des Namens nachverfolgt wird. Es liegt weiterhin in Ihrer Verantwortung, ein solches System zu erstellen. Die ASP.NET MVC 4-Vorlage unterstützt Sie hier mit einem zusätzlichen Schritt, in dem der Benutzer automatisch die Möglichkeit erhält, seinen Anzeigenamen einzugeben. Dieser wird anschließend in einer lokalen Mitgliedschaftstabelle gespeichert. Dies ist nur erforderlich, wenn sich ein Benutzer zum ersten Mal an einer bestimmten Website anmeldet. Anders gesagt, das Formular in Abbildung 3 dient dazu, die Registrierung mit der ersten Anmeldung zu verknüpfen.

Abbildung 3: Erste Anmeldung und vollständige Registrierung an der Website

Mit dem an dieser Stelle angegebenen Namen wird das ASP.NET-Authentifizierungscookie erstellt, was definitiv den Kreis schließt. Sie haben mithilfe von Twitter Anmeldeinformationen überprüft, den Benutzer gebeten, seinen Anzeigenamen einzugeben, und Sie haben ein normales Authentifizierungscookie erstellt. Ab sofort funktioniert alles in ASP.NET für Websites mit Authentifizierung wie gewohnt.

Die standardmäßige ASP.NET MVC 4-Projektvorlage speichert Benutzerdaten in einer lokalen MDF-Datenbank, die in dem App_Data-Ordner erstellt wurde. Die Tabelle wird mithilfe der einfachen Mitgliedschafts-API verwaltet, die aus dem Webseitenframework vererbt wurde.

Im folgenden Code wird gezeigt, wie die Beispielprojektvorlage den Anzeigenamen der Seite aus Abbildung 3 erhält:

var loginData = OAuthWebSecurity.SerializeProviderUserId(
  result.Provider, result.ProviderUserId);
var name = OAuthWebSecurity
  .GetOAuthClientData(result.Provider)
  .DisplayName;
  return View("ExternalLoginConfirmation",
  new RegisterExternalLoginModel {
    UserName = result.UserName,
    ExternalLoginData = loginData
  });

Mit dem Aufruf von „GetOAuthClientData“ greifen Sie auf beliebige Informationen zu, die der Anbieter von Twitter über den angemeldeten Benutzer freigibt. In der Methode „ExternalLoginConfirmation“ finden zwei Aktionen statt, die in folgendem Code zusammengefasst werden:

OAuthWebSecurity.CreateOrUpdateAccount(provider, providerUserId, model.UserName);
OAuthWebSecurity.Login(provider, providerUserId, createPersistentCookie: false);

In der ersten Zeile wird der neue Datensatz in der lokalen Mitgliedschaftsdatenbank für die Anwendung eingerichtet. In der zweiten Zeile wird das Authentifizierungscookie erstellt. Die Standardvorlage bietet zahlreiche Datenbanktabellen wie „UserProfiles“ und „webPages_OAuth­Membership“. Letztere speichert einen Datensatz mit dem Namen des Anbieters (also Twitter), der anbieterspezifischen ID für den Benutzer und einem Zeiger auf eine interne ID, die den Benutzer eindeutig in der UserProfiles-Tabelle mit dem Anzeigenamen identifiziert, den er auf der in Abbildung 3 gezeigten Seite gewählt hat. 

Abschließende Überlegungen

Das OAuth-Protokoll verwaltet die Interaktion zwischen einem Anbieter und einer Clientanwendung. Twitter, Facebook und ein paar weitere bekannte soziale Netzwerke machen ihre APIs über „OAuth“ verfügbar. Eine Clientanwendung kann die Twitter-API aus zwei Hauptgründen verwenden: reine Benutzerauthentifizierung und Nutzung anhand des Anbieters im Namen eines zustimmenden Benutzers. In beiden Fällen muss sich die Clientanwendung am Anbieter anmelden und ein Zugriffstoken abrufen. Das Zugriffstoken ist zeitlich beschränkt (kann aber programmgesteuert aktualisiert werden) und autorisiert, nur die Operationen auszuführen, die der Endbenutzer beim Eingeben der Anmeldeinformationen genehmigt hat (siehe Abbildung 2). In Abhängigkeit von den Anforderungen der Anwendung kann sie unterschiedliche Maßnahmen durchführen, nachdem sie das Zugriffstoken erhalten hat. Das Token kann verwendet werden, um z. B. die E-Mail-Adresse abzurufen und sie in einem anwendungsspezifischen Mitgliedschaftssystem zu speichern. Es kann auch zum Veröffentlichen von Beiträgen im Namen des Benutzers verwendet werden. Das ASP.NET-Authentifizierungscookie bleibt auch dann gültig, wenn der Benutzer die Verbindung mit Twitter trennt. Eine Anwendung kann jedoch ohne Verbindung mit Twitter keinen Beitrag veröffentlichen.

Die ASP.NET MVC-API, insbesondere die OAuthWeb­Security-Klasse, löst das Authentifizierungsszenario unkompliziert, deckt aber die Interaktion mit dem sozialen Anbieter über das Abrufen eines Anzeigenamens hinaus nicht ab. Sie lässt sich auch gut in den einfachen Mitgliedschaftsanbieter von Webseiten zum lokalen Speichern von Twitter- und Facebook-Benutzernamen integrieren.

Dino Esposito ist der Autor von „Architecting Mobile Solutions for the Enterprise” (Microsoft Press, 2012) sowie „Programming ASP.NET MVC 3” (Microsoft Press, 2011) und Mitverfasser von „Microsoft .NET: Architecting Applications for the Enterprise“ (Microsoft Press 2008). Esposito lebt in Italien und ist ein weltweit gefragter Referent für Branchenveranstaltungen. Sie können ihm auf Twitter unter twitter.com/despos folgen.

Unser Dank gilt dem folgenden technischen Experten für die Durchsicht dieses Artikels: Mani Subramanian (Microsoft)
Mani Subramanian ist seit 12 Jahren an der Entwicklung und am Testen von Softwareprojekten beteiligt. Sein Fokus liegt auf SOA, Cloud Computing und core.net.