In previous entries I talked about what Mobile Services can provide in terms of authentication, but how do you actually use it?  That answer is quite simple.

private async void MainPage_Loaded(object sender, RoutedEventArgs e)
{
    try
    {
        var client = new MobileServiceClient("APP URL", "APP KEY");
        var user = await client.LoginAsync(MobileServiceAuthenticationProvider.Facebook);

        // do something
    }
    catch (InvalidOperationException)
    {
        MessageBox.Show("Login Failed");
    }
}

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

In this example, we are forcing the user to login each time the application starts.  This does a few things:

• Negates the need for us to store the User Id on the device.  Since the UserId will be used as a key value, we will need to obtain this value in some way
• If using a singleton approach to handling your Mobile Service Client reference this will automatically set the internal authentication of the client
• OAuth dictates that the underlying tokens used for authorization expire after a given amount of time.  By leveraging this approach, Mobile Services can be allowed to check whether the token is expired or not and issue new ones

So the experience for the user is the application starts and, if it is the first time or the user has not granted rights to the app for their social profile (Facebook in this case) they will be presented with the touch friendly Facebook login.  Subsequent application launches will bypass the login screen and return the UserId as stored by Mobile Services.  This ID is of the form:

: Numeric value

This value is very important.  Its quite normal to use this as the key value for user specific data in your Mobile Services tables. While the above process ensures the token is expired, it is recommended that the application NOT log in each time.  To improve the user experience, you should be caching this value on the device.  Using this value (and the associated Mobile Service Token obtained from the MobileServiceUser object coming from the Login operation), at the conclusion of each request verify that a 401 (Unauthorized) is not received.  If it is received than the Login flow must be executed.

Josh Twist has an excellent on handling this case here: http://www.thejoyofcode.com/Handling_expired_tokens_in_your_application_Day_11_.aspx

Quick note: The concept of a “filter” was renamed to “HttpMessageHandler”.  The third parameter to the constructor for MobileServiceClient which represents an array or these “interceptors”.

Additional documentation can be found here: http://msdn.microsoft.com/en-us/library/windowsazure/system.net.http.httpmessagehandler.aspx