Il presente articolo è stato tradotto automaticamente.

Cutting Edge

L'autenticazione tramite social network in ASP.NET MVC 4

Dino Esposito

Come vedo le cose, la maggior parte dei siti Web che hanno bisogno di autenticare gli utenti utilizzeranno gateway autenticazione sociale.In questo contesto, un gateway di autenticazione sociale è semplicemente la piattaforma di autenticazione esposta pubblicamente dal popolare social network come Twitter e Facebook.Se pensate che torna ai primi giorni di ASP.NET, non si può fare a meno di notare qualche somiglianza tra l'idea dietro l'iniziativa di passaporto e gateway autenticazione sociale di oggi.Certamente non sono la stessa cosa, ma in entrambi gli scenari è possibile riconoscere l'obiettivo di semplificare la vita degli utenti riducendo il numero delle credenziali che devono tenere traccia.

Utilizzando lo stesso set di credenziali ha Pro e contro.Da un lato si abbassa la barriera di sicurezza intorno la tua privacy.Sempre utilizzando lo stesso username e password, dare agli hacker più tempo per indovinare i vostri segreti; allo stesso tempo, si espongono informazioni molto di più una volta hackerati.D'altra parte, però, utilizzando le stesse credenziali ripetutamente rende più facile per voi per collegare e provare nuovi servizi.Per i proprietari di servizio questo è grande perché possono vedere il numero di utenti di crescere più rapidamente, il che significa che il servizio ha più probabilità di avere successo.

In poche parole, sempre più siti Web che mira ad attirare una grande base di utenti oggi offrono la doppia opzione di registrazione scegliendo le proprie credenziali o attraverso un gateway di autenticazione di rete sociale.La tendenza è così interessante che nella versione più recente di ASP.NET MVC 4 troverete un quadro ad hoc per autenticare gli utenti attraverso una serie di reti sociali.In questo articolo esaminerò il codice che si ottiene dal modello di progetto MVC 4 ASP.NET .Gateway di autenticazione sociale utilizzano il protocollo di autenticazione aperta (OAuth), che risulta per essere piuttosto un protocollo dettagliato.Pertanto, il codice risultante non è esattamente banale e può richiedere qualche ulteriore spiegazione.

Il modo più rapido per l'autenticazione di MVC

ASP.NET MVC ti dà la possibilità di avviare la codifica da un modello di codice che include già l'autenticazione.Il modello di applicazione di Internet che si ottiene con ASP.NET MVC 4 estende il supporto per gateway sociale.Supponiamo, quindi, che si dispone di un nuovissimo progetto di applicazione di Internet.Sulla prima compilazione del codice, niente di speciale accade.Pagina in Figura 1 vi informa che nessun servizio di autenticazione esterno è stato ancora abilitato.

Figura 1 il ASP.NET MVC 4 modello quando non è configurato alcun servizio di autenticazione esterna

È possibile abilitare i servizi supportati facendo alcuni leggeri cambiamenti al file Global. asax codebehind.In ASP.NET MVC 4 che è consigliabile che i progetti includono una cartella App_Start con xxxConfig classi che eseguono operazioni di inizializzazione.Tali classi sono semplici contenitori di metodi static che organizzano meglio il codice di avvio dell'applicazione.Ecco un'istantanea:

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

Il metodo RegisterAuth contiene il codice per lasciare che gli utenti accedi utilizzando il loro account da altri siti come Facebook e Twitter:

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

La classe OAuthWebSecurity viene dal framework di pagine Web e si trova nello spazio dei nomi Microsoft.Web.WebPages.OAuth. Questa classe include la funzionalità di base del protocollo OAuth poiché è implementata nella libreria DotNetOpenAuth (DNOA) (vedi dotnetopenauth.net).

Al fine di autenticare gli utenti contro una rete sociale che è innanzitutto necessario creare un'applicazione all'interno della rete sociale. Così hai bisogno di un'applicazione di Twitter e un'applicazione di Facebook per autenticare gli utenti via Twitter e Facebook all'interno del tuo sito. Molto probabilmente potrai creare un'applicazione Facebook/Twitter con lo stesso nome come il tuo sito e configurarlo per il collegamento al sito Web. Che cosa si fa riferimento qui come un'applicazione Facebook/Twitter non è in realtà una vera e propria applicazione; Inoltre, ha una speciale devel­token oper per accedere a Twitter, Facebook e altri social network. In passato rate di questa rubrica dedicata alla programmazione di Facebook ho ricoperto questo aspetto abbastanza approfondito. Ai fini del presente articolo, un'applicazione Twitter/Facebook è costituito da una coppia di stringhe — quella nota come la chiave e l'altro noto come il segreto. La chiave e il segreto sono univocamente associati con l'applicazione sociale. Si inizializza OAuthWebSecurity passando la chiave e segreto per ogni rete sociale si intende sostenere.

Aggiungendo semplicemente chiamate al RegisterTwitterClient e RegisterFacebookClient, l'interfaccia utente del progetto campione cambia per mostrare le opzioni di registrazione come pulsanti. Se un utente sceglie il pulsante Accedi, lei sarete reindirizzata al sito Facebook/Twitter per procedere con l'autenticazione. Se tutto funziona bene lei allora sarete reindirizzata al sito originale ed essere riconosciuta da ASP.NET come un utente autenticato.

Suona come una cosa molto semplice, giusto? Beh, ci sono un sacco di grattacapi dettagli sotto il cofano.

Prendendo l'itinerario OAuth per l'autenticazione

Quando l'utente fa clic sul pulsante Twitter Account/ExternalLogin si sposta il sito. Diamo un'occhiata al codice per il metodo (il codice si trova nel file AccountController.cs):

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

La classe ExternalLoginResult è una sorta di wrapper per il seguente codice che veramente fa il lavoro di contatto con il gateway di autenticazione:

OAuthWebSecurity.RequestAuthentication(Provider, ReturnUrl);

La classe ExternalLoginResult è una classe helper anche trovata nel file AccountController.cs. Si noti che nel codice del template di progetto il nome del provider viene risolto guardando l'attributo nome del pulsante:

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

Alla fine della giornata, il metodo RequestAuthentication riceve il nome del provider di autenticazione (Twitter, Facebook o qualsiasi altro i provider supportati) e l'URL di ritorno. Per impostazione predefinita, OAuthWebSecurity supporta i seguenti fornitori: Twitter, Facebook, LinkedIn, Google, Microsoft e Yahoo. Internamente, il metodo utilizza la libreria DNOA di svolgere il compito. Vediamo che cosa succede se l'utente sceglie di eseguire l'autenticazione tramite Twitter.

Come primo passo, viene visualizzata la pagina di autenticazione di Twitter predefinito per l'utente. La pagina contiene il nome dell'applicazione Twitter che sta conducendo l'attività — si tratta di tFun nell'esempio mostrato Figura 2. Quando si configura un'applicazione di Twitter, si indicano anche le autorizzazioni, è necessario concedere l'applicazione dopo l'accesso. Configurando correttamente la domanda sociale si può dare il sito Web ASP.NET il permesso di seguire gli utenti nuovi o post per conto dell'utente connesso. Questo non è il caso con l'applicazione di esempio.

Figura 2 l'autenticazione via Twitter

Se l'utente immette credenziali di Twitter (o la rete sociale di scelta) riconosce come valida, il sito di Twitter reindirizza all'URL restituito fornito. Il metodo successivo dove si riguadagnare controllo passato l'autenticazione è ExternalLoginCallback. Che cosa si sa a questo punto è solo che l'utente che sta tentando di accedere all'applicazione è stato correttamente riconosciuto come un utente di Twitter. Non si sa nulla su di lei, nemmeno il suo nome utente. Appena posso pensare di un'applicazione che ha bisogno di utenti autenticati e può beatamente ignorare nomi utente o indirizzi di posta elettronica. Torna dalla fase di autenticazione, solo l'applicazione riceve un codice ma non è ancora stato autorizzato per accedere a livello di codice l'API di Twitter. A tal fine, il codice ricevuto in questa fase deve essere scambiato per un token di accesso (di solito limitata nel tempo per impedire l'abuso). Questo è lo scopo della chiamata al metodo VerifyAuthentication che si trova nel corpo di ExternalLoginCallback. L'oggetto AuthenticationResult che tornare da VerifyAuthentication riporta alcune informazioni sull'utente. Le informazioni effettive che si ottiene possono essere leggermente diverse a seconda del provider; Tuttavia, esso solitamente contiene almeno l'username.

Dall'autenticazione di appartenenza

L'autenticazione di un utente è solo il primo passo. Successivamente, è necessario tenere traccia dell'utente per nome all'interno del sito. In un classico sistema di appartenenza ASP.NET prima di visualizzare un form di login, convalidare le credenziali e quindi creare un cookie di autenticazione con nome utente e, facoltativamente, altre informazioni chiave. Twitter o Facebook si salva l'onere di organizzare un modulo di login e convalida le credenziali, oltre l'onere non banale di archiviazione e gestione degli account con informazioni sensibili come le password.

La linea di fondo, è però, che quasi ogni applicazione che ha bisogno di utenti autenticati anche ha bisogno un sistema di appartenenza dove ogni utente normale è monitorata da nome. Costruzione di un tale sistema è ancora vostra responsabilità. Il modello MVC 4 ASP.NET viene in soccorso offrendo un ulteriore passaggio dove l'utente è automaticamente data la possibilità di inserire il suo nome, che viene quindi salvato in una tabella di appartenenza locale. Ciò è necessario solo la prima volta che un utente accede a un determinato sito. In altre parole, la forma mostrata Figura 3 ha lo scopo di unire la registrazione e il login prima.

Figura 3 primo Login e la registrazione completa del sito

Il nome immesso in questa fase viene utilizzato per creare il cookie di autenticazione ASP.NET , che chiude definitivamente il cerchio. Utilizzato Twitter per verificare le credenziali, ha chiesto all'utente di inserire il suo nome visualizzato e creato un cookie di autenticazione regolare. Da ora in poi, tutto funziona come di consueto in ASP.NET per siti soggetti ad autenticazione.

Il modello di progetto MVC 4 ASP.NET predefinito salva i dati utente in un database locale mdf creato sotto la cartella App_Data. La tabella è gestita utilizzando l'API di appartenenza semplice ereditato dal framework di pagine Web.

Il codice riportato di seguito viene illustrato come il modello di progetto di esempio ottiene il nome visualizzato della pagina del Figura 3:

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
  });

La chiamata a GetOAuthClientData è dove si accedere qualsiasi che il provider Twitter condivide informazioni sull'utente loggato. Nel metodo ExternalLoginConfirmation accadono due cose fondamentali, riassunti nel codice seguente:

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

La prima linea stabilisce il nuovo record nel database locale di appartenenza per l'applicazione. La seconda riga crea effettivamente il cookie di autenticazione. Fornisce il modello predefinito per un mucchio di tabelle di database come seguito e webPages_OAuth­l'adesione. Quest'ultima tabella memorizza un record con il nome del provider (che è, Twitter), il provider ID univoco per l'utente e un puntatore a un ID interno che identifica in modo univoco l'utente nella tabella di seguito con la visualizzazione nome utente se stessa ha scelto nella pagina mostrata Figura 3.

Considerazioni finali

Il protocollo OAuth gestisce l'interazione tra un fornitore e un'applicazione client. Twitter, Facebook e pochi altri popolari social network espongono le loro API tramite OAuth. Un'applicazione client può utilizzare l'API di Twitter per due scopi principali: autenticazione utente normale e operano contro il provider per conto di un utente consenziente. In entrambi i casi l'applicazione client deve accedere al provider e ottenere un token di accesso. Il token di accesso è limitato nel tempo (ma a livello di codice può essere rinfrescato) ed è autorizzato a eseguire solo le operazioni che l'utente finale approvato quando entrò le credenziali (vedere Figura 2). Che cosa succede una volta che l'applicazione contiene un token di accesso dipende dalle esigenze dell'applicazione. Il token può essere utilizzato per recuperare, per dire, l'indirizzo di posta elettronica e memorizzarla in un sistema di appartenenze specifiche dell'applicazione. Il token è utilizzabile anche per inviare per conto dell'utente. Il cookie di autenticazione ASP.NET rimane valido anche quando l'utente si disconnette da Twitter. Un'applicazione, tuttavia, non è possibile postare se l'utente è disconnesso da Twitter.

L'API di MVC ASP.NET — in particolare il OAuthWeb­classe di sicurezza — affronta lo scenario di autenticazione piacevolmente, ma esso non copre interagendo con il provider sociale di là di ottenere un nome visualizzato. Si integra bene con il provider di appartenenze semplice di pagine Web per l'archiviazione di Twitter e Facebook nomi utente localmente.

Dino Esposito è l'autore di "Architettura Mobile soluzioni per l'impresa" (Microsoft Press, 2012) e "programmazione ASP.NET MVC 3" (Microsoft Press, 2011) e coautore di "Microsoft .NET: Architecting Applications for the Enterprise" (Microsoft Press, 2008). Vive in Italia e partecipa spesso come relatore a eventi del settore in tutto il mondo. Seguirlo su Twitter a twitter.com/despos.

Grazie all'esperto tecnica seguente per la revisione di questo articolo: Mani Subramanian (Microsoft)
Subramanian mani è stato coinvolto nello sviluppo e test di progetti software negli ultimi 12 anni con un focus su SOA, cloud computing e core. NET.