Metro Nuggets

Bitesized tidbits for building Modern (Metro) apps.

Using WebAccountProvider with Facebook on Windows 10 Mobile

For a while now, there have been a few ways for developers to allow a user to sign into Facebook:

  • They could use the WebAuthenticationBroker, which launched a hosted window the user could enter their details in;
  • They could use their own hosted WebView (WebBrowser on Silverlight) and send the user to the same place as the WebAuthenticationBroker and handle the navigations themselves;
  • They could use the Facebook Client SDK (in Silverlight), or the Windows SDK for Facebook (in Universal apps);
  • Manually create the URI scheme that would launch the Facebook app and have the app do the authentication for you.

With Windows 10, there’s a new way for developers to be able to authenticate their users, and that’s the WebAccountProvider. This allows account providers (like Facebook) to provide authentication using their Windows 10 app. Using this approach would mean your users would never have to leave the comfort of your app to get authenticated.

So what does all this mean? What is WebAccountProvider? It’s possible, in Windows 10, for apps to allow developers to explicitly use them as an authentication provider, without having to use URI schemes and callbacks to be set up by the calling app. The difference between this approach and the URI/Callback approach is this can be done silently so the user can potentially never leave your app but still get successfully authenticated.

IMPORTANT NOTE

All of this blog post is based on the current Windows 10 Facebook beta that came out recently. If you submit a Windows 10 app to the store before this version leaves beta, this code will not work as the user will likely be using the non-beta Facebook app. If you only depend on this approach, then your users will not be able to authenticate with Facebook, so it’s important to have some fallback methods.

This is now available in the non-beta version of Facebook for Windows 10 too, so will work for anyone who has updated their app.

Check for Account Providers

The first thing you need to do is see if there is a provider available for the service you’re looking to use; if there’s no app provider, then you should have a fallback method to use.

// Check whether there is an app for the provider we want to use (facebook)
var provider = await WebAuthenticationCoreManager.FindAccountProviderAsync("https://www.facebook.com");

To get the provider, you give FindAccountProviderAsync an id for that provider; in Facebook’s case, that’s their website address (including https). If the Facebook app is installed, this will return a provider, and if the app is not installed, this will be null and you should proceed to whatever fallback method you’re choosing to use.

Check Silently First

The first check you’ll want to do is a silent call to that provider to see whether it has any account details that have already been stored by the app. So we create our WebTokenRequest. For this sample, I’ll use the basic public_profile scope, but you can use whatever set of permissions you need for your app. These would be included as part of the request, and if you have more than one scope for your app, include them as a comma separated string (eg, “public_profile,email,user_friends”).

var request = new WebTokenRequest(provider, "public_profile", "");

// We need to add the redirect uri so that the facebook app knows it's actually us.
// This will use the store id you assigned in your facebook developer portal
request.Properties.Add("redirect_uri", "msft-");

And then we make our silent call to the provider using GetTokenSilentlyAsync

result = await WebAuthenticationCoreManager.GetTokenSilentlyAsync(request);

Once we have the result, we can check whether we have our credentials, whether the user cancelled, the process encountered an error, or whether there is some user interaction required. We do this by checking the result’s ResponseStatus property.

User Interaction Required

If your result has come back with a status of UserInteractionRequired, this means that there were no stored credentials for this provider and we need to make a subsequent call to RequestTokenAsync.

result = await WebAuthenticationCoreManager.RequestTokenAsync(request);

And again, once you have your result, you can check the ResponseStatus to see how next to proceed.

Extracting the Token

Once you have got a Success status, then you can get the user’s access token and their Facebook username

var tokenResponse = response.ResponseData[0];
var accessToken = tokenResponse?.Token;
var username = tokenResponse?.WebAccount?.UserName;

And that’s it.

Fallback Methods

As noted throughout this post, it’s good practice to have at least one fallback method in case the user doesn’t have the Windows 10 Facebook app installed. The different fallback methods would be:

  1. The URI Scheme (be sure to use FindUriSchemeHandlersAsync to check for “fbconnect”). If that fails, then;
  2. WebAuthenticationBroker

Source Code

There is a working sample on Github.

Windows SDK for Facebook

I should imagine the Windows SDK for Facebook released in the Summer will be getting an update to also support this authentication approach.

SL

Advertisements

2 responses to “Using WebAccountProvider with Facebook on Windows 10 Mobile

  1. Pingback: Dew Drop – December 17, 2015 (#2154) | Morning Dew

  2. Ugo February 10, 2016 at 11:57

    hi, any way to know all the providers installed on a device? a sort of enumeration?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: