Caching and handling expired tokens in Azure Mobile Services managed SDK

Article
03/12/2014

A while back my colleague Josh Twist had a great series of posts about A**zu**re **Mo**bile Services (or “Zumo”, as he called). This was when the service was in its infancy, and some things changed, but the content is still excellent. One of the topics was about caching authentication tokens, so that the application wouldn’t need to authenticate the user every time, instead relying on a cached version of the authentication token obtained via one of the calls to the LoginAsync method in the client. And in the following post, he talked about how to handle the case when those tokens were expired using service filters. It is a great post, but the example uses an old (and now unsupported) version of the client SDK for managed code, so I decided to post an updated version of it.

As I mentioned before, the “service filters” which existed in the initial client SDK were replaced by the HttpClient primitives, most notably the HttpMessageHandler class (or its subclass DelegatingHandler, which is more commonly used). Since there was already a good HTTP pipeline with a type which did exactly what the original service filters did, it didn’t make sense to have two, so the service filters were dropped. As a side note, the original client SDK for mobile services didn’t use the HttpClient primitives because they were not released as a portable library; when it did, we changed the mobile services client SDK to use it.

So on to the code. The AuthHandler inherits from the DelegatingHandler class, and when it’s SendAsync method is called, it first sends the message along to the rest of the pipeline, and if it gets an unauthorized response (401), it first tries to log in to the mobile service, then resends the request with the appropriate authentication header set. This handler also calls a delegate that saves the user information, so that the application will have it the next time it’s launched. One last thing which is worth noting is that, since the request can be sent multiple times, my implementation is cloning it, as the request body may not be read more than once.

class AuthHandler : DelegatingHandler
{
public IMobileServiceClient Client { get; set; }
private Action<MobileServiceUser> saveUserDelegate;
public AuthHandler(Action<MobileServiceUser> saveUserDelegate)
{
this.saveUserDelegate = saveUserDelegate;
}
protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
if (this.Client == null)
{
throw new InvalidOperationException("Make sure to set the 'Client' property in this handler before using it.");
}
// Cloning the request, in case we need to send it again
var clonedRequest = await CloneRequest(request);
var response = await base.SendAsync(clonedRequest, cancellationToken);
if (response.StatusCode == HttpStatusCode.Unauthorized)
{
// Oh noes, user is not logged in - we got a 401
// Log them in, this time hardcoded with Facebook but you would
// trigger the login presentation in your application
try
{
var user = await this.Client.LoginAsync(MobileServiceAuthenticationProvider.Facebook);
// we're now logged in again.
// Clone the request
clonedRequest = await CloneRequest(request);
// Save the user to the app settings
this.saveUserDelegate(user);
clonedRequest.Headers.Remove("X-ZUMO-AUTH");
// Set the authentication header
clonedRequest.Headers.Add("X-ZUMO-AUTH", user.MobileServiceAuthenticationToken);
// Resend the request
response = await base.SendAsync(clonedRequest, cancellationToken);
}
catch (InvalidOperationException)
{
// user cancelled auth, so lets return the original response
return response;
}
}
return response;
}
private async Task<HttpRequestMessage> CloneRequest(HttpRequestMessage request)
{
var result = new HttpRequestMessage(request.Method, request.RequestUri);
foreach (var header in request.Headers)
{
result.Headers.Add(header.Key, header.Value);
}
if (request.Content != null && request.Content.Headers.ContentType != null)
{
var requestBody = await request.Content.ReadAsStringAsync();
var mediaType = request.Content.Headers.ContentType.MediaType;
result.Content = new StringContent(requestBody, Encoding.UTF8, mediaType);
foreach (var header in request.Content.Headers)
{
if (!header.Key.Equals("Content-Type", StringComparison.OrdinalIgnoreCase))
{
result.Content.Headers.Add(header.Key, header.Value);
}
}
}
return result;
}
}

Now to the application to test it out. The client is created passing an instance of the AuthHandler class defined above. Since the handler needs a reference to the client (to be able to log in if the token has expired), the client is then passed on to the handler after it’s created. Maybe not the cleanest of the designs, but it solves the chicken-and-egg problem which we have (client needs handler in its constructor; handler also needs a client). When the client calls the operation on the table, the handler will be invoked and re-login the user if necessary.

private async void btnStart_Click(object sender, RoutedEventArgs e)
{
try
{
AddToDebug("Started");
var authHandler = new AuthHandler(SaveUser);
var client = new MobileServiceClient(
MobileService.ApplicationUri,
MobileService.ApplicationKey,
authHandler);
authHandler.Client = client;
MobileServiceUser user;
if (TryLoadUser(out user))
{
client.CurrentUser = user;
}
var table = client.GetTable<Item>();
var items = await table.Take(3).ToEnumerableAsync();
AddToDebug("Items: {0}", string.Join(", ", items.Select(i => i.Name)));
}
catch (Exception ex)
{
AddToDebug("Error: {0}", ex);
}
}
private static bool TryLoadUser(out MobileServiceUser user)
{
object userId, authToken;
if (ApplicationData.Current.LocalSettings.Values.TryGetValue("userId", out userId) &&
ApplicationData.Current.LocalSettings.Values.TryGetValue("authToken", out authToken))
{
user = new MobileServiceUser((string)userId)
{
MobileServiceAuthenticationToken = (string)authToken
};
return true;
}
else
{
user = null;
return false;
}
}
private static void SaveUser(MobileServiceUser user)
{
ApplicationData.Current.LocalSettings.Values["userId"] = user.UserId;
ApplicationData.Current.LocalSettings.Values["authToken"] = user.MobileServiceAuthenticationToken;
}

If you want to test this yourself, you don’t really need to wait for 30 days (the default expiration of the authentication tokens issued by the mobile services) to see if it works. Since the tokens are signed with the mobile service master key, if that key is changed, then all the cached tokens will become invalid. Be careful that any systems or apps which are using that master key will stop working.

To do that, first run the app once to get a token and save it on the application storage. Once that is done, go to your mobile service dashboard page, and select the “manage keys” option in the bottom.

At that point, select the “regenerate” option, and that will change the key used by the service.

Now if you run the application again, if the client tries to use the cached token the request will fail with an unauthorized (401) response, and the handler will initiate another login action for the client.

And that’s the implementation for caching and revalidating tokens in the current Azure Mobile Services managed SDK.

Caching and handling expired tokens in Azure Mobile Services managed SDK

Additional resources