2014-10-02 3 views
44

Uso Owin per autorizzare tramite Google oAuth. Ecco come i miei biscotti sono configurati:UseCookieAuthentication vs. UseExternalSignInCookie

// Enable the application to use a cookie to store information for the signed in user 
app.UseCookieAuthentication(new CookieAuthenticationOptions 
{ 
    AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, 
    LoginPath = new PathString("/Authentication/Login") 
}); 
// Use a cookie to temporarily store information about a user logging in with a third party login provider 
app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie); 

Così sto utilizzando sia UseCookieAuthentication e UseExternalSignInCookie e sembra ridondante. Quale di questi due AuthenticationTypes dovrei specificare per i metodi IAuthenticationManager (SignIn, SingOUt, ecc.)? O dovrei tenere solo uno di loro?

Aggiornamento . Ciò che mi confonde di più è il metodo SignIn:

private async Task SignInAsync(ApplicationUser user, bool isPersistent) 
{ 
    AuthenticationManager.SignOut(DefaultAuthenticationTypes.ExternalCookie); 
    var identity = await UserManager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie); 
    AuthenticationManager.SignIn(new AuthenticationProperties() { IsPersistent = isPersistent }, identity); 
} 

Così signsout da ExternalCookie, ma i segni in ApplicationCookie.

risposta

74

Hai bisogno di tutti loro, se vuoi che Google acceda per lavorare. Ecco come funziona. Nella pipeline OWIN sono presenti tre componenti middleware: (1) il middleware di autenticazione dei cookie in esecuzione in modalità attiva, (2) un'altra istanza di middleware di autenticazione dei cookie ma in modalità passiva e (3) middleware di autenticazione di Google. Sarà così.

app.UseCookieAuthentication(new CookieAuthenticationOptions 
{ 
    AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, 
    ... 
}); // Active 

app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie); // Passive 

app.UseGoogleAuthentication(...); 

Quando c'è una 401, l'utente viene reindirizzato a Google. Lì, il tuo utente effettua l'accesso e Google convalida le credenziali. Google quindi reindirizza l'utente alla tua app. A questo punto, il middleware di autenticazione di Google ottiene le informazioni di accesso, applica una concessione (leggi cookie esterno) e cortocircuita la pipeline OWIN e reindirizza all'URL di callback esterno, che corrisponde al metodo di azione ExternalLoginCallback di AccountController. Quindi, a questo punto in cui la richiesta arriva alla tua app come risultato del reindirizzamento, ottieni il cookie esterno con il nome utente e le richieste via email.

Per leggere questo cookie e recuperare i dati (nome utente, ecc.) Da Google, si utilizza il middleware di autenticazione cookie in esecuzione in modalità passiva. Poiché questo middleware viene eseguito in modalità passiva, è necessario che legga il cookie. Questo è ciò che accade quando la chiamata a AuthenticationManager.GetExternalLoginInfoAsync() viene effettuata nel metodo di azione ExternalLoginCallback. A quel punto, è stata stabilita l'identità dal cookie esterno e questa identità contiene solo il nome e le richieste email di Google.

In genere, a questo punto sarà necessario recuperare le informazioni specifiche dell'utente dall'archivio dati dell'applicazione e aggiungere ulteriori attestazioni all'identità. Quindi, chiami Signout sul middleware cookie esterno, che assicurerà anche che il cookie esterno non venga più restituito espirandolo. Pertanto, utilizzando le informazioni sull'identità disponibili in quel momento, il metodo UserManager.FindAsync viene chiamato nel metodo di azione ExternalLoginCallback, che dovrebbe restituire all'utente tutte le attestazioni specifiche dell'applicazione. Usando questa nuova identità, chiami SignIn sul middleware di autenticazione dei cookie in esecuzione in modalità attiva. Questo assicura che venga creato un nuovo cookie. Rispetto al cookie esterno, questo nuovo cookie contiene tutte le rivendicazioni specifiche dell'applicazione.Successivamente, si ottiene questo cookie e il middleware di autenticazione dei cookie in esecuzione in modalità attiva legge attivamente il cookie e stabilisce l'identità con l'elenco completo di tutte le rivendicazioni specifiche dell'applicazione.

Quindi, se non si chiama Signin, non si creerà quel cookie contenente tutte le rivendicazioni specifiche dell'applicazione. Ma poi spetta a te utilizzare qualche altro meccanismo. Il comportamento out-of-box è che un cookie locale contenente tutte le rivendicazioni specifiche dell'applicazione viene creato tramite tale chiamata a SignIn e successivamente letto dal middleware cookie in esecuzione in modalità attiva.

AGGIORNAMENTO: Ho creato un post sul blog per spiegare come è possibile andare via senza utilizzare due istanze di middleware cookie. http://lbadri.wordpress.com/2014/10/14/barebones-asp-net-mvc-google-signin-through-owin-middleware/

+2

I bit UserManager.FindAsync sono ora nascosti nel SignInManager per Identity 2.2.0 (che non è OSS) ma sono sicuro che questo è ancora ciò che viene fatto sotto il cofano. Reflector non è di grande aiuto a causa delle ottimizzazioni. Quindi, se qualcuno sta cercando di seguire quel bit e non trovarlo nel codice di esempio, è per questo. Questo è il modo in cui è stato fatto in 1.0 e possibilmente 2.0 ma è stato estratto in 2.2 e forse un po 'diverso in vNext. Apprezzo che questo non sia un post di Identity, ma è probabile che molti stiano guardando il codice di esempio da quel framework facendo quanto sopra. – rism

+1

cosa potrebbe succedere se chiamiamo AuthenticationManager.GetExternalLoginInfoAsync() restituisce loginInfo la prima volta, ma se accediamo nuovamente a un altro, restituisce null. Restituisce nuovamente loginInfo dopo aver riciclato il pool di app. @Badri – fcartu

+0

Qualsiasi motivo per cui non posso semplicemente usare il middleware passivo? Se l'unica cosa di cui ho bisogno è l'identità dell'utente (come Facebook: 133454545454). – LOST

5

"SignOut (DefaultAuthenticationTypes.ExternalCookie)" è quello di "pulizia, il cookie esterno" come per la risposta di Hao Kung https://stackoverflow.com/a/20575643/2710179

C'è una bella implementazione nel progetto Microsoft.aspnet.identity.samples che può essere scaricato da Nuget. In questa implementazione usano: -

var userIdentity = await manager.CreateIdentityAsync(this, DefaultAuthenticationTypes.ApplicationCookie); 

"ExternalCookie" è il "valore predefinito utilizzato per l'ExternalSignInAuthenticationType configurato" Credo che questo significa che è usato come l'uso cookie temporaneo per verificare l'utente contro una vista esterna

Problemi correlati