In questa parte della serie dirò qualcosa sul codice utilizzato per eseguire l'autenticazione client-flow (vedere linkografia): ovviamente affinchè tutto funzioni occorre aver seguito con religiosa cura i passi di configurazione esposti nelle puntate precedenti.
Il codice esposto permette l'autenticazione presso l'IdP Facebook usando il relativo SDK nativo: Xamarin.Facebook.Android.
Come è intuibile questa parte è totalmente "annegata" nel progetto Xamarin.Android: al termine delle operazioni di login l'SDK rilascia un token, che è quello rilasciato da Facebook, e che viene salvato come proprietà della classe Settings.
private class facebookCallBack : Java.Lang.Object, IFacebookCallback, IDisposable
{
#region IFacebookCallback implementation
public void OnCancel()
{
}
public void OnError(FacebookException p0)
{
}
public void OnSuccess(Java.Lang.Object p0)
{
LoginResult loginResult = (LoginResult)p0;
Settings.AuthToken = loginResult.AccessToken.Token;
App.GoToMainPage();
}
#endregion
}
Tengo a specificare che questo token è quello rilasciato da Facebook, e non può essere usato per consultare direttamente i servizi Azure Mobile.
Il passo successivo, quindi, è quello di inviare questo token ai servizi di autenticazione del backend Azure Mobile, che lo verificheranno (con l'ausilio di App ID e App Secret configurati nel portale) e se riconosciuto come valido (cioè veramente emesso da Facebook a fronte di una autenticazione corretta) verrà restituito un nuovo token emesso questa volta direttamente dai servizi azure.
var token = new JObject(); token["access_token"] = Settings.AuthToken;
var user = await client.LoginAsync(MobileServiceAuthenticationProvider.Facebook, token);
Questa operazione è possibile con la sola chiamata LoginAsync dell'oggetto MobileServiceClient.
Come nel caso del server-flow sarà solo il token rilasciato dai servizi Azure a essere inserito in ogni richiesta verso il backend. Anche in questo caso questa aggiunta avviene in modo silente semplicemente usando l'oggetto client.
Questa modalità di autenticazione pur avendo induscutibili vantaggi (non vengono presentate web browser o similari per inserire userid e password) ha anche alcuni svantaggi evidenti.
- Occorre studiare un nuovo SDK: quello dell'IdP prescelto. E, aggiungo, occorre studiarlo bene.
- Occorre avere l’SDK disponibile per il client che si sta creando. Qui abbiamo usato Xamarin.Android, ma me si fosse usata un'altra piattaforma di siluppo non è detto che l'SDK esista
- In generale la soluzione è più difficile da implementare ma anche quella che permette una migliore esperienza utente
- Occorre osservare qualora si usi l’SDK di un IdP potrebbe esserci la necessità di avere anche la relativa app installata: per esempio facebook sino a non molto tempo fa aveva necessità di avere la propria app installata sul dispositivo per utilizzare il proprio SDK.
- Se la app nativa dell'IdP è installata sul dispositivo l'SDK di default permette l'autenticazione usando l'account già inserito in questa. Nel nostro caso se nel device è presente la app Facebook correttamente autenticata con un utente, lanciando la nostra app semplicemente ci viene chiesto se si vuole usare l'account già inserito, senza dover ridigitare userdid e password. Questo, se da un lato potrebbe rappresentare un gran comodità, potrebbe anche essere un comportamento non desiderato.
Linkografia
