Getting the updates

As has been the case, you can get the latest updates to your project via the NuGet Package Explorer. Right-click the project node or the references node in your project in the solution explorer, then select the “Manage NuGet Packages” option: In the NuGet dialog, select the “Updates” option in the left, and type “mobileservices” in the search box. You should see the latest version of the mobile services-related packages, with the latest version (1.0.402). Select the packages and click the “Update” button. Notice: there are some dependencies which cannot be updated at this moment, so don’t use the “Update All” button. If you update only the mobile service-related packages, it will automatically update any dependencies that it works well with.

Custom Scopes for Social Authentication Providers

This has been a long-standing feature request, which is present in the node.js backend. When you log in to the .NET backend, you can ask in the server for a token to talk to the authentication providers. By default, the token only grants some basic information about the user. Now, in the .NET backend, you can also request additional login scopes so that the access token which you receive at the server can be used to retrieve more information from the authentication provider. Like in the node.js backend, this feature is available for Facebook, Google and Microsoft accounts. Like in the node.js backend, the login scopes can be defined using app settings, which can be set in the “configure” tab in the portal: MS_FacebookScope, MS_GoogleScope and MS_MicrosoftScope (for Facebook, Google and Microsoft accounts, respectively). Let’s look at an example of those scopes being used. I’ve set up a .NET mobile service with authentication with two of the providers mentioned above (Facebook and Microsoft). I’ll also add a controller that talks to the providers to retrieve information about the logged in user:

That’s some basic information, but if my application also needed the user’s e-mail or some other information, the access token granted by the service login didn’t have access to that. But if we request additional scopes during the login, by setting the MS_FacebookScope and MS_MicrosoftScope app settings, we’d get the additional information we need: And running the client app again we’d get the newly requested information (after the user grants the application access to the additional info).

One final note about requesting additional scopes: as a good general rule, only request the minimum information you need from the user. Many users don’t like giving out a lot of information to the apps they use, so they may simply give up using your app just because they’re being asked too much when logging in.

Single Sign-On Support for Windows Store Applications

When you use the mobile services SDK in a Windows Store application, every time the app calls the method LoginAsync in the MobileServiceClient passing the authentication provider the authentication window is show, and the user has to enter their credentials and click the “sign in” button in the authentication page – even if the user selected the “remember me” button in the provider’s login page (Windows may have cached the credentials so that they don’t need to be entered, but the user still needs to click the button to log in). That’s because by default the cookies from an authentication session are not preserved, so that when the provider page is shown again, there will be no cookies from a previous authentication to identify the user. There’s an overload to LoginAsync which takes an additional flag which indicates that the client should cache the cookies in the authentication sessions, so that the next time LoginAsync is called, the authentication dialog will just be shown briefly and then automatically dismissed, making for a better user experience. In the client shown in the previous section, all we need to do is to use the additional overload and pass true to the second parameter of LoginAsync.

There’s one change which needs to be done in the server side as well, if you haven’t yet. To enable this scenario, the application needs to be associated with an app in the Windows Store, since the package SID (one of the app identifiers) for that application needs to be stored in the service. You will get a package SID by creating the app in the Windows Store Dashboard, and you can see how to find that value in the tutorial to register the app package for Microsoft authentication. If your app will not use Microsoft authentication (for example, use Facebook or Twitter), you won’t need to copy the client id / secrets, but you’ll still need to copy the package SID in the microsoft account settings under the identity tab in the portal.