READ THIS FIRSTUpdate: 3-4-2016: If you're finding this blog and looking for information related to Azure Mobile Services, I'd strongly recommend checking out Azure Mobile Apps. Azure Mobile Apps is a new version (consider it a v2) of Azure's mobile backend support. All of the same features of Azure Mobile Services are there, with a lot of other very cool features to go along. You can read more about Azure Mobile Apps, and how to transition from Azure Mobile Services, here.
If you’ve been using Azure Mobile Services lately, you may have noticed a warning appearing in your logs with the following message:
Version 1 of the Mobile Services JWT token has been deprecated. Please contact [email protected] to find out how to update your code.
First, don’t freak out. There’s a pretty good chance this doesn’t affect you at all. Due to an unfortunate misstep, this warning has been showing up for some people that aren’t actually affected. Read on to see if you need to make any changes.
Essentially, you only need to worry about this message if you’re doing custom auth with your Mobile Service. If you are, you most likely found it in one of these locations:
- Custom Auth with Mobile Services and LensRocket
- Authentication with Azure Mobile Services
- Custom Identity in Mobile Services (from Josh Twist)
The reason that you’re affected if you’re doing custom auth is that you’re generating your own JWT tokens. If you’re using any of the built in auth (Facebook, Google, Microsoft, Twitter) than your Mobile Service generates the JWT for you and your service is already updated. If you are doing custom auth, read on for the instructions on how to update your code.
Updating the auth code
Thankfully, the changes required to move to version 2 are very simple and they can all be done in the server side scripts. Here we have the code previously used to specify the contents of the JWT (note I’ve left off the code to make this URL friendly, merge it, etc):
We need to make two alterations to this code. First the kid value needs to change from an integer to a string, so “0”. Second, the ver value needs to change to 2. Our updated code will look like this:
There is one other change you’ll have to make if you’re also doing custom claims. If you’re specifying a urn:microsoft:credentials as part of the j2 value above, you’ll need to change it to match this shape:
Version 1 tokens will continue to work for some time though you’ll see that warning pop up in your logs if you continue to issue V1 tokens. Thankfully the changes are small. As always, I would advise making your changes against a test service prior to making the changes against a service backing a production app. You can read more about the changes on the Azure Mobile Services blog.
Don't I have to pass in token in the header each time I do a call to the mobile services right? whether I get it from 3rd party like FB or custom login?
If I set 'logged in' user only permission to insert then it will need a way to validate that you are who you say you are and logged in. Does MobileServiceClient object knows currentuser that somehow?
Provided you're using one of the client SDKs to talk to Mobile Services, you just need to set the userID and Auth token values for the MobileServiceClient.CurrentUser, then those values will automatically be included as headers with requests against your Mobile Service. If you're not using the SDKs then yes, you'd need to pass them with each request. Mobile Services will automatically verify that the User ID and Auth Token are valid with every request before the request gets to the script layer. Once a request is in the script, you can rest assured that the User.UserId property is a real user ID and belongs to the user making the request.
This should be put on the official Zumo docs. There aren't any client side examples on the docs.
Doc link: http://azure.microsoft.com/...
I am trying to write up just the custom authentication. I followed your steps in your other posts, but now I am a little confused on trying to update what is in this post. For the NewClaim.js where exactly is that supposed to go?
It goes in the JWTCreation seen just above it.