I am having an unusual hard time finding an example of how to develop a multi-user Xamarin.Forms app. Imagine you wanted to develop an app for UWP, iOS and Android that users can log into and then "do stuff".
It does not matter what - for example taking notes for later access.
Since I am using Microsoft Azure, I would love to have an example which makes use of Azure Active Directory B2C for authentication (including the usage of identity providers such as Microsoft, Facebook, Google, etc.) and Azure Mobile App Service / Azure SQL, etc.
While there are samples available that show how to use ADB2C I didn't find anything related to how you would implement a multi-user app (e.g. best strategies for the database schema, access management and how this works best with an own Restful API backend and how to include it in your client code, i.e. Model, Controller,...)
Does anyone of you happen to know an end-to-end sample for this type of Scenario?
Best regards,
Christian.
To setup authentication for B2C, I would recommend MSAL. Here are some samples:
https://github.com/Azure-Samples/active-directory-b2c-xamarin-native
There are also samples available for the WebApi.
This is a simple Xamarin Forms app showcasing how to use MSAL to authenticate users via Azure Active Directory B2C, and access an ASP.NET Web API with the resulting token.
If you want to know how to setup your database to actually store user data, I would recommend using the claims provided in the token to identify the user. The best way identify the user reliably would be to use the objectId claim. It stays the same even if the user changes their email address.
The claims can also be used to show user information in your app, e.g. display name or email. You need to add the scope profile to your authentication request to get this data.
Related
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?
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...
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?
AFAIK, for app service authentication with Microsoft Account, you need to create the application in Microsoft Account Developer Center, then you need to add Client Id and Client Secret for your Microsoft Account provider under "Settings > Authentication / Authorization" of your App Service application. For more details, you could refer to Microsoft Account authentication.
Based on your scenario, you could only use the Client-managed authentication for Microsoft Account. Additionally, the app service authentication for Microsoft Account uses LiveSDK for initiating the sign-in process. Though, I'm not familiar with Xbox Live services sign-in, based on my understanding, I assumed that you could not achieve this purpose for now.
Scenario: I already have a registered multi-tenant web application that is compatible with Azure SSO. I'm now in the process of developing an iOS application that will support SSO authentication for the app as well.
Based on the example provided in https://azure.microsoft.com/en-us/resources/samples/active-directory-ios/ I created a Native application for the iOS app with delegated permissions from my WebApp (ref: https://stackoverflow.com/a/29810124).
This works for any user that exists within the AAD that the app was created. However, as soon as I want to SSO from a different domain that has previously authorized the WebApp I get an error:
Application with identifier 'CLIENT_ID_HERE' not found in directory DOMAIN_HERE.onmicrosoft.com
This implies that the native application is not multi-tenant? This seems a bit bizarre considering it should be possible for users outside of the domain to SSO to an application.
Right now, for my browser based SPA I'm simply able to manually call the common Azure login page to consent and get an authorization code for a user. I then send this code to a backend (the WebApp) that performs the OAuth handshake and gets a valid token. This does not require a client_secret from the application because the SPA isn't actually performing token retrieval.
So when I attempted to use the WebApp's client_id instead (similar to what https://stackoverflow.com/a/27033816 is suggesting) I was met with an error with the Azure AD iOS SDK requiring that I provided a client secret as well. It seems that the SDK is abstracting a fair amount of this and grabbing a token for you rather than performing a step when I can simply get an authorization code and send it to my WebApp.
TLDR: My requirements are very similar to the ones outlined in multiple-tenant, multiple-platform, multiple-services single sign-on using Azure Active directory where I have multiple clients (browser, iOS, Android) that all need to be able to use Azure SSO. I'm assuming the mobile apps should be able to use my existing WebApp to authenticate the users.
The question posed in the answer of the previous SO post somewhat explains my issue:
How can my mobile app access my multi-tenant web api on behalf of the user?
References
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-authentication-scenarios#native-application-to-web-api
https://github.com/Azure-Samples/active-directory-dotnet-webapi-multitenant-windows-store
At present the native app which register on the Azure portal doesn't support multi-tenant. You may consider using the V2.0 endpoint which also support the Microsoft accounts.
TLDR: My requirements are very similar to the ones outlined in multiple-tenant, multiple-platform, multiple-services single sign-on using Azure Active directory where I have multiple clients (browser, iOS, Android) that all need to be able to use Azure SSO. I'm assuming the mobile apps should be able to use my existing WebApp to authenticate the users.
Did you mean that have different font-end and the Multi-Tenant Web Application is the back-end? In this scenario, there is no need to register another native client application on the portal, you can refer here about add authentication for the iOS app.
So the majority of Microsoft's tutorials use their AAD SDK to generate OAuth access tokens whereas I needed to simply get an authorization_code to send up to a backend that's registered as an existing multi-tenant web application so it could properly generate a token using its own client_id.
This was done using the correct redirect_uri in the AD OAuth code documentation:
For native & mobile apps, you should use the default value of urn:ietf:wg:oauth:2.0:oob
Note that sending up urn:ietf:wg:oauth:2.0:oob will actually result in a schema error for the multi-tenant OAuth login page (https://login.windows.net/common/oauth2/authorize) so you must use https://login.microsoftonline.com/common/oauth2/nativeclient instead.
I am building a Xamarin app that will need to have users authenticated and each user will have a role. Would Azure AD OAuth 2.0 be a good solution for this scenario? Each person that downloads my app would register which would create an Azure AD user? At first I thought Azure AD was strictly for managing users within an organizations and not a way to authorize thousands of users of an app. Would I be able to seamlessly integrate Azure OAuth into my app without having to leave my app (like I would need to do with Google or Facebook OAuth)? Thanks for any clarification that would help me better understand!!
The Xamarin experience can leverage ADAL / MSAL PCL libraries for authentication (in Alpha right now) - available on nuget. You need to look at the new Azure AD Business to Consumer (B2C) offering (in preview right now).
Note that the OAuth experience this provides leverages WebViews inside of your app to perform user authentication so it doesn't differ from what you wish to avoid.
While you could theoretically change that behaviour by custom coding a solution it's probably worth considering the benefits of handing off authentication and only having to deal with the resulting tokens.
I've originally used Web API 2 with Individual Accounts so that users can create a new account by supplying a username/email and password which is stored in my DB.
I'm now looking to put this API into Azure API service and have looked at the documentation about authentication but this mostly talks about external authentication. Can we use Individual Accounts with Azure API or will I need to handle this myself within the actual API?
Also, with the third party authentication all the examples use a redirected website (FaceBook, Google) to get the user to log in. I want to call this from a mobile app so does it support extenal authentication using API calls or will I have to do that myself?
Thanks
The is no problem in using the security you originally used. The documentation you are looking at describes how to do claim based authentication, authentication with azure ad and internally secure your application with service principals. When using a mobile device, you can go with claims authentication. However you should first figure out what you really want to do.
I want to store user information to a db after a user successfully logged in via a social provider (google, facebook, etc.) without calling an extra api on the client side.
In azure mobile services this is done by creating a class that inherity from e.g. GoogleLoginProvider and then by overwriting the CreateCredentials method.
See this post: Save information immediately after Google login in Azure Mobile Services (.NET Back-end)
But how can I archive the same behaviour in Azure App Services?
Thanks
Unfortunately this is not possible with App Service authentication. The authentication happens outside of your application and there aren't currently any direct hooks into the authentication pipeline. This also means you will not be able to inject custom claims into the ClaimsIdentity.
We are aware of some of these scenarios and want to try and address them, but don't have any timelines to share at this point. I believe the separate API call into the backend will be required in order for you to implement your registration. As far as implementing role-based access control, you will likely need to store the additional user metadata elsewhere.