Facebook Login for Windows Phone

Facebook apps can use one of several login flows, depending on the target device and the project. This guide takes you through the login flow for native apps in Windows Phone. If you are building an app for Windows desktop, you should follow our guide to manually build a login flow.

Here are the steps for using Facebook Login with Windows Phone:

Before You Start

Some important things to note before you implement the Login flow:

  • The process is designed to work when the person logging in has version 5.2 of the Facebook app for Windows Phone installed. If that app or that version of the app is not installed, then the person will be taken to the Windows Store and can download it.

  • Third-party, Microsoft-supported Facebook SDK for .NET contains special helper functions to integrate Facebook Login even faster. We recommend you use that SDK if you are able to, as it offers a number of added benefits, however documentation and support for it is not provided by Facebook.

  • You must also register your app for a URI association, as described in Microsoft's documentation.

Checking Login Status

Windows Phone apps must create their own way of storing access tokens when a person has logged in. When that indicator is not there, apps should proceed on the assumption that they are logged out. If someone is logged out, then your app should redirect them to the Login dialog at an appropriate time, for example if they click a Login button.

Logging In

Prepare your app by inserting your Windows Phone app's Store ID without dashes in the App Dashboard:

NOTE: There is currently a bug which will prevent Facebook Login for Windows Phone from working if you have any entries in the Valid OAuth redirect URIs field in the Advanced section of your app settings. This can be worked around by adding https://m.facebook.com/dialog/return/ms in this field.

Opening the Login Dialog

You can send someone to the Login dialog from your app by launching the following URI association:

fbconnect://authorize?
  client_id={your-facebook-app-id}&
  scope={permissions-requested}&
  redirect_uri=msft-{ProductID}://authorize

{ProductID} refers to the same ProductID that you added to the App Dashboard above (again without the dashes).

All parameters should be properly URL Encoded. The scope parameter is optional, but can contain any of the login permissions that are available as a comma separated list.

Example

fbconnect://authorize?
  client_id=675854675761202&
  scope=basic_info,user_photos&
  redirect_uri=msft-4ce6ab44b7f9442482de17535b713cde%3a%2f%2fauthorize

This will fail if your Facebook app id client_id does not match the ProductID that you have set in the App Dashboard as above.

Handling Login Dialog Response

If someone successfully logs in, the URI association of your app will be automatically triggered, meaning they will be sent to your app, along with an access token:

msft-{ProductID}://authorize/?
  access_token={user-access-token}&
  expires_in={expiration-time-of-token}

If the login is unsuccessful or the person cancels, the URI association will still be triggered, but this time with error error_code, error_description, and other parameters:

msft-{ProductID}://authorize/?
  error=access_denied&
  error_code=200&
  error_description=Permissions%20Error&
  error_reason=user_denied

Confirm Identity

For security reasons you may want to perform an automated check to confirm the access token you receive belongs the person that your app expects, and that your app generated the token.

We provide the following Graph API endpoint that your app can make a web request to inspect access tokens:

GET graph.facebook.com/debug_token?
     input_token={token-to-inspect}
     &access_token={app-token-or-admin-token}

This endpoint takes the following parameters:

  • input_token. The token you need to inspect.
  • access_token An app access token or an access token for a developer of the app.

The response of the API call is a JSON array containing data about the inspected token. For example:

{
  "data": {
    "app_id": 138483919580948, 
    "application": "Social Cafe", 
    "expires_at": 1352419328, 
    "is_valid": true, 
    "issued_at": 1347235328, 
    "metadata": {
        "sso": "iphone-safari"
    }, 
    "scopes": [
        "email", 
        "publish_actions"
    ], 
    "user_id": 1207059
  }
}

The app_id and user_id fields help your app verify that the access token is valid for the person and for your app. For a full description of the other fields, see the Getting Info about Access Tokens guide.

Storing Access Tokens and Login Status

At this point in the flow someone is authenticated and logged into your app. Your app is ready to make API calls on their behalf. Before you do this, you should store the person's access token and the login status.

Storing Access Tokens

After your app receives the access token, the token should be stored so it's available to all parts of the app when it makes API calls. There is no specific process here, however most apps will add the token alongside some unique user ID in a datastore or even a web database.

Please see our note about the size of access tokens in the access token document.

Track Login Status

Your app should store a person's login status, which helps maintain their login and avoids having to make additional calls to the Login dialog. Whatever procedure you chose, now you know what your login status checking code is looking for.

Logging Out

You can log people out of your app by un-setting the login status indicator you added. You should also remove the access token if you stored it.

Logging someone out is not the same as revoking login permission. The latter actually permanently removes previously granted authentication which your app can be performed separately. Because of this, build your app so it doesn't automatically force people who have logged out back to the Login dialog.