none
MVC4 OAuth Microsoft Account identity doesn't match my Mobile Services UserId

    Question

  • Why doesn’t my #MobileServices UserId for my Microsoft Account match the ProviderUserId of my MVC4 web app defended by SimpleMembership OAuth?

    If I authenticate using my Microsoft Account to my MVC4 web app, I was hoping that I'd be able to start making User authenticated MobileServices REST calls from my MVC server-side code by manually creating a JWT as described by Josh Twist's 12 days of Zumo http://www.thejoyofcode.com/Exploring_custom_identity_in_Mobile_Services_Day_12_.aspx .  But, there doesn't appear to be any correlation between the two notions of an ID.  So, from my website's login, I don't have enough data to actually make the JWT and have the MobileServices code think that the call is actually me.

    I read this forum post and it didn't really help me.  I feel that my website and the mobileservice are both using OAuth, so they should both represent me using a common Id.

    http://social.msdn.microsoft.com/Forums/en-US/azuremobile/thread/ed045134-6559-4db3-9257-95b97b48587a

    What am I missing?

    Wednesday, January 23, 2013 10:03 PM

All replies

  • Trying to clarify things a bit more:

    MVC4 OAuth membership data is stored in backing DB, at dbo.webpages_OAuthMembership.  The values originate from the Identity Providers and are not "MVC" specific in any way.

    Mobile Services provides a UserId in the various Clients and server side scripts.

    An actual sample FB user is represented like this in MVC vs. Mobile Services:
    MVC Membership: "1235304525"
    Mobile Services UserId: "Facebook:1235304525"

    An actual sample Twitter user is represented as:
    MVC Membership: "69390433"
    Mobile Services UserId: "Twitter:69390433"

    So, those two providers can be correlated because they essentially match.

    An actual sample Microsoft Account user is represented as:
    MVC Membership: "7575052169c244dc"
    Mobile Services UserId: "MicrosoftAccount:3066e0aaac686b01346f3a2c90b9a9e9"

    An actual sample Google user is represented as:
    MVC Membership: "https://www.google.com/accounts/o8/id?id=AItOawkD5pBwyETDdUbPu4Z1IBkgzDQjV4HxmBI"
    Mobile Services UserId: "Google:100779806071460922150"

    Clearly, these two providers do not come close to correlating.

    For Google and Microsoft Account, where do those Mobile Services UserIds originate?  How do they relate to the Identity Providers?


    Thursday, January 24, 2013 8:54 PM
  • Hi Nate,

    Apologies for the delay - can you confirm that you're using the same Google/Microsoft Account key and secret in both your Mobile Service and MVC apps?

    Thanks

    Josh


    http://twitter.com/joshtwist

    Monday, January 28, 2013 10:27 PM
    Owner
  • The results of my testing and various exchanges with @joshtwist via Twitter are summarized here.  I hope you brought your secret decoder ring.

    MVC4 OAuth membership data is stored in a backing DB, at dbo.webpages_OAuthMembership.  The values stored there originate from the Identity Providers, by way of DotNetOpenAuth's ASP.Net specific providers, and are not "MVC" specific in any way.  MVC code can get at this stored external auth provider data using code such as:

    ICollection<OAuthAccount> accounts = OAuthWebSecurity.GetAccountsFromUserName(User.Identity.Name);

    Mobile Services provides a UserId in its various Clients, server-side scripts and its access-token (a JWT).  Using the existing Azure Portal and various supplied Mobile Services clients, the UserId values are obtained from external authentication providers using various authentication flow methods.

    The MVC websites used in my testing used actual domain names, whereas the Mobile Services were a subdomain of the https://*.azure-mobile.net.  Since the return URLs were inherently different, they required unique AppId and Secret Keys with each Identity Provider.  Restated, each site and each service had their own AppId/Secrets for Identity.

    An actual sample FB user is represented like this in MVC vs. Mobile Services:
    MVC website 1: "1235304525"
    MVC website 2: "1235304525"
    MVC website 3: "1235304525"
    Mobile Service 1: "Facebook:1235304525"
    Mobile Service 2: "Facebook:1235304525"

    An actual sample Twitter user is represented as:
    MVC website 1: "69390433"
    MVC website 2: "69390433"
    MVC website 3: "69390433"
    Mobile Service 1: "Twitter:69390433"
    Mobile Service 2: "Twitter:69390433"

    Using Facebook and Twitter, I get a consistent "UserId" across MVC and Mobile Services regardless of AppId/Secret.  So, those two providers can be correlated because they essentially match.

    An actual sample Microsoft Account user is represented as:
    MVC website 1: "7575052169c244dc"
    MVC website 2: "7575052169c244dc"
    MVC website 3: "7575052169c244dc"
    Mobile Service 1: "MicrosoftAccount:3066e0aaac686b01346f3a2c90b9a9e9"
    Mobile Service 2: "MicrosoftAccount:4d93d5a4438d66c4900b0c2da4aeef77"

    Using Microsoft Account, Mobile Service represents the same user with a different UserId.  This is explained by @JoshTwist as: "because we _support_ implicit grant flow with Live (client flow) we have to use the PUID which is not the same across Live apps."  MVC4 (via DotNetOpenAuth) authenticates Microsoft Account users using an "Authorized Code" grant flow, which does provide consistent "UserId" regardless of AppId/Secret.

    An actual sample Google user is represented as:
    MVC website 1: "https://www.google.com/accounts/o8/id?id=AItOawkNSHh_MWboua7qeSoX6zB39xKffkYyxHY"
    MVC website 2: "https://www.google.com/accounts/o8/id?id=AItOawkRUNsMVaAx8Ur5fzT9580GCiDNub6KPNs"
    MVC website 3: "https://www.google.com/accounts/o8/id?id=AItOawkD5pBwyETDdUbPu4Z1IBkgzDQjV4HxmBI"
    Mobile Service 1: "Google:100779806071460922150"
    Mobile Service 2: "Google:100779806071460922150"

    Using Google, Mobile Service represents the same user with the same UserId regardless of AppId/Secret.  Unfortunately, MVC4 (via DotNetOpenAuth) authenticates with an OpenID flow which represents the same user with a different UserId across websites.  If my research on this is correct, Google dev docs at https://developers.google.com/accounts/docs/OpenID explain this as "This identifier is also a "directed identity", that is, Google returns a different value to each relying party."

    In the end, if I don't want to write/maintain custom Authentication code, I'll have to stick with limiting my Website/Mobile App users to using Facebook and Twitter.

    Wednesday, January 30, 2013 3:24 PM
  • Nate great test. I am quite puzzled about this myself as well. When using fiddler you could see the zumo way also uses the Authorized Code method. There is magic happening at the point the code is returning to the zumo login service.

    I would really like to know about that magic as well. Please post an answer if you find any ...

    I guess there is some algorithm going on the clientId, or client secret. Als the scope used is wl.basic ...


    Thursday, January 31, 2013 11:16 PM
  • Nate, I think you can find your answer here:

    http://social.msdn.microsoft.com/Forums/en-US/azuremobile/thread/ed045134-6559-4db3-9257-95b97b48587a

    • Proposed as answer by RockSolid1982 Friday, February 01, 2013 9:31 PM
    Friday, February 01, 2013 9:30 PM
  • Thanks André.

    I was tracking your question too as I could see we were chasing something similar.

    In the Authorization Grant flow (which we can see *some of* via Fiddler using our local c# client), we have visibility up until that last handshake that occurs between the MobileService SERVER and the Live servers.  So, we don't get a chance to look at the "magic" that happens.  It is a server to server exchange.

    Paul and Josh commented in your question about which piece of data is used for the Live connection specifically.  Although Josh had told me via Twitter that the PUID was used, and then Paul stated the UID was used.

    I was really most interested in a "no code" solution for this.  I can get that with Facebook and Twitter.  So, for now, that is all I'm supporting.  I'd venture to say that 95% of my Live users have a Facebook account.  I wouldn't say the same is true in reverse though.

    Monday, February 04, 2013 4:22 PM
  • Hi Nate,

    I just posted a step-by-step guide on flowing a Facebook authentication from an ASP.NET MVC app to a backing Azure Mobile Service at http://blogs.msdn.com/b/carlosfigueira/archive/2013/06/25/exposing-authenticated-data-from-azure-mobile-services-via-an-asp-net-mvc-application.aspx - if you're still having problems with it, hopefully it will help.

    Thanks,
    Carlos.


    Carlos Figueira

    Tuesday, June 25, 2013 8:58 AM
    Moderator