azureunity-game-engineazure-mobile-servicesxbox-live

Xbox Live sign-in running Unity to authenticate Azure App Services / Mobile services


I've got the Unity Xbox Live services example up and running allowing me to sign-in to my Microsoft Account via Xbox Live services in Unity.

I've also got Azure App Services (Mobile services) running in Unity to query and persist my data. App Services supports authentication out of the box including Microsoft Account support.

Does anyone know if I can use the authentication from Xbox Live services sign-in to authentication my web calls against my Microsoft Account in App Services?


Solution

  • It gets complicated :) although I can understand the frustration. Let me give a quick overview, but I'm happy to give more details as needed.

    When dealing with sign-in, the first step is authentication - and there are three choices on such systems with Microsoft 1. MSA, or Microsoft Account, which is what most consumer systems use, such as Xbox. 2. AAD, or Azure Active Directory, which is typically for enterprise applications. 3. S2S, or Server to Server, which is typically done either with an SSL certificate or shared secret. (Note this is also similar to the app secret mentioned above, although app secret is less secure since the secret is with the app itself, but this and MSA do go together).

    These three systems are very different in goals, designs and requirements so there isn't really an option to unify them.

    Now lets assume that you are using only #1 above - signing in with MSA. You might wonder why you can't take the token returned for one set of services and use it with another. Now we are into the realm of user privacy and security isolation. Have you noticed when you sign into a game on the PC with XboxLive that you get a dialog box asking if it is okay? That is the consent dialog and is required so that malicious apps can't steal a token for one part of a system (say your outlook.com sign-in) and use it to grab data from elsewhere (onedrive, xbox, etc) without the user saying "yes, that is okay". This same thing happens with systems like Facebook, etc - it is a fairly standard system.

    So, to enable this, each time you ask MSA for a token, you have to specify the site you are going to use it with, so MSA knows what consent to ask for - and to ensure it stays only to that site.

    tl;dr - doing security right means more hassles :) But the good news is that the underlying system should be able to detect these and prevent the user from having to present a sign-in for each site - just one sign-in, but possibly multiple consent dialogs. And more code for the developer...