locked
How authentication id is determined for same SNS account RRS feed

  • Question

  • I created the Mobile App and upload it to the App Services (=AppSvr1). Then set twitter authentication for the TwitterApp(=TwApp1).

    This combination returns NameIdentifier of ClaimsPrincimal as '024dxxx' for my twitter account.

    I created some other AppServices like AppSvr2 and AppSvr3 and uploaded the same mobile app to those AppServices. These bind to TwApp2 and TwApp3.

    These AppServices returns the same NameIdentifier as '3bf28xxx' for my twitter account.

    Why I test these is I use NameIdentifier to access user data resources of my service, so the same identifier for the same account should be returned when I recreated AppServices environment if it's broken by some accident.

    Anyway, the results are the id from the original AppServices and the one from new environments are different, but these new environments return the same one.

    Then, my question is 

    1.Why the id from original and new are different.

    2.How NameIdentifier is determined.

    Any info is helpful.



    cyclops

    Sunday, October 29, 2017 8:52 AM

Answers

  • It looks like it's going to be easiest for you to create a new Mobile App in the portal.  You may be interested in this article, specifically:

    The plan is that stable_sid will be the default sid for all newly-created applications. In order to prevent breaking existing apps, the old sid behavior has to stay around in some form. This is why you see both the sid and the stable_sid in your claims. You can enable stable_sid to become the default sid (which is recommended) by setting an App Setting of 'WEBSITE_AUTH_HIDE_DEPRECATED_SID' to 'true' in the portal.

    Let me know if this article answers your questions.  



    Software Developer - Azure App Service, Mobile Apps Team

    • Marked as answer by cyclops2 Saturday, November 11, 2017 2:25 AM
    Friday, November 3, 2017 5:40 PM

All replies

  • Hi Cyclops,

    This is a rather unique setup you've described, we're trying to replicate it now.  I'm not sure why you're seeing different results from the original environment than the new ones.  We'll get back to you with an update when we finish our repro and investigation.


    Software Developer - Azure App Service, Mobile Apps Team

    Tuesday, October 31, 2017 9:14 PM
  • Sorry, this is because my setup is wrong.

    WEBSITE_AUTH_HIDE_DEPRECATED_SID=true doesn't work properly.

    After setting it, it returns the same sId as original does.

     

    I ask you...

    1.The same SNS account should return the same sId regardless the combination of any Twitter App and Apps Services and Mobile App?

    2.I forgot to state that My Mobile app was created in early 2016. It means setting WEBSITE_AUTH_HIDE_DEPRECATED_SID is needed to return stable sid.

    Can I modify my Mobile App returns stable sid without setting it, or recreating Mobile App is easy than it?


    cyclops

    Wednesday, November 1, 2017 12:34 AM
  • It looks like it's going to be easiest for you to create a new Mobile App in the portal.  You may be interested in this article, specifically:

    The plan is that stable_sid will be the default sid for all newly-created applications. In order to prevent breaking existing apps, the old sid behavior has to stay around in some form. This is why you see both the sid and the stable_sid in your claims. You can enable stable_sid to become the default sid (which is recommended) by setting an App Setting of 'WEBSITE_AUTH_HIDE_DEPRECATED_SID' to 'true' in the portal.

    Let me know if this article answers your questions.  



    Software Developer - Azure App Service, Mobile Apps Team

    • Marked as answer by cyclops2 Saturday, November 11, 2017 2:25 AM
    Friday, November 3, 2017 5:40 PM