Home > View Post

Generating your own ZUMO auth token (Day 8)

Most developers using Mobile Service are familiar with Mobile Services authentication – which makes it uber easy to sign your users in to your Mobile Service via Twitter, Facebook, Google and Microsoft Account. When we sign a user in, we issue the client a ZUMO JWT token that is used to identify that user on subsequent roundtrips via the X-ZUMO-AUTH header, as documented in our HTTP API reference.

A JWT, or JSON Web Token, is a simple token formed of three sections separated by ‘.’

The first section is the JWT header which declares that the thing is a JWT and  the encoding used by the signature.
The second is the claims set, which is where you put any claims. In the case of Mobile Services, this is where we put the userId.
The third is the signature, which is used to ensure that nobody has tampered with the first two sections.

Because the signature is generated using a secret key, we know that it must have been created by somebody who has the secret key (and therefore we trust them). In the case of Mobile Services, this is your Master Key.


You can access the master key by clicking on the MANAGE KEYS command in the DASHBOARD and QUICKSTART tabs of the Windows Azure portal.

Since you have the access key, and know how to create JWTs, there’s nothing stopping you from creating your own Mobile Services tokens for your users, if you want to add an additional authentication mechanism for example. We have always kept an eye on composition with other services in Azure (and beyond) and this is a great scenario. For example, imagine you have your own identity system with usernames and passwords for your existing website. Then you could easily add code to that site to create a Mobile Services auth token to allow clients to access Mobile Services with a custom provided identity.

Here’s some JavaScript that can be used in nodeJS (or even in a Mobile Services server script) to generate a ZUMO JWT:

And to test it out, try creating a table in Mobile Services and setting the READ permission to Authenticated User only, now hit it with CURL or Fiddler and some random x-zumo-auth header:

curl –H “x-zumo-auth: randomgoop” https://yourservice.azure-mobile.net/tables/foo

Which will result in a 401 unauthorized response “The authentication token’s signature was malformed or signed by a different key.”


However, with a genuine token generated by the zumoJwt function as follows:

var expiry = new Date().setUTCDate(new Date().getUTCDate() + 1); // expires in one day from now 
var jwt = zumoJwt(expiry, "your-aud", "unique string for this user", "yourmasterkey");

curl –H “x-zumo-auth: JWTHERE” https://yourservice.azure-mobile.net/tables/foo

Then you’ll get some data! What’s more, on the server if you inspect the user parameter in a script, you’ll see that the userId property, is the userId you specified in the JWT.

This was day 8 in the series, the twelve days of ZUMO.

Josh Post By Josh Twist
11:36 PM
28 Dec 2012

» Next Post: Fetching a basic user profile in Mobile Services (Day 9)
« Previous Post: Unit testing Mobile Services scripts (Day 7)

Comments are closed for this post.

© 2005 - 2022 Josh Twist - All Rights Reserved.