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. For more information on Azure B2C, see the Azure AD B2C documentation homepage.
Please note this sample is known to have frequent issues using Social IDPs. Please check the issues on Github for more detail. To guarantee this sample runs correctly, we recommend using local accounts.
To run this sample you will need: - Visual Studio 2015 - An Internet connection - An Azure AD B2C tenant
If you don't have an Azure AD B2C tenant, you can follow those instructions to create one. If you just want to see the sample in action, you don't need to create your own tenant as the project comes with some settings associated to a test tenant and application; however it is highly recommend that you register your own app and experience going through the configuration steps below.
From your shell or command line:
git clone https://github.com/Azure-Samples/active-directory-b2c-xamarin-native.git
You can run the sample as is with its current settings, or you can optionally register it as a new application under your own developer account. Creating your own app is highly recommended.
IMPORTANT: if you choose to perform one of the optional steps, you have to perform ALL of them for the sample to work as expected.
You can find detailed instructions on how to create a new app on this page Make sure to:
This sample requires your B2C app to have a policy of type "Sign Up or Sign In". You can follow the instructions in this tutorial to create one. Once created, replace the following value in the
TaskClient/App.cs file with your own policy name. All B2C policies should begin with
public static string SignUpSignInpolicy = "b2c_1_susi";
public static string ClientIDand replace the value with the Application ID from the app registration portal from Step 2.
Authorityone line below and change it to point to your Azure AD B2C tenant. Your Azure AD B2C tenant name most likely takes the format
Choose the platform you want to work on by setting the startup project in the Solution Explorer. Make sure that your platform of choice is marked for build and deploy in the Configuration Manager. Clean the solution, rebuild the solution, and run it. Click the Sign in or Sign up button at the bottom of the application screen. On the credentials gathering screen, choose sign up and go through the sign up experience. As soon as you successfully sign up, you will be transported to a screen where you can create new tasks. Also, the button at the bottom of the screen will turn into a Sign out button. Create some random tasks, then close the application and reopen it. You will see that the app retains access to the API and retrieves the tasks list right away, without the need to sign in again. Sign out by clicking the Sign out button and confirm that you lose access to the API until the next interactive sign in. Note that now that you signed your test user up, you will be able to choose the sign in path at authentication experience time.
The structure of the solution is straightforward. All the application logic and UX reside in TaskClient (portable). TaskClient.Droid and TaskClient.iOS both include a WelcomePageRenderer and a TasksPageRenderer class, both used for assigning values at runtime to the
PlatformParameters property of the paged. The
PlatformParameters construct is used by MSAL for understanding at runtime on which platform it is running - so that it can select the right authentication UX and token storage. Please note, MSAL does not need
PlatformParameters for UWP apps. Also, technically TaskPage would not need a renderer either, given that in this sample that page never triggers interactive authentication. However we included one in case you want to add that functionality. TaskClient.Droid requires one extra line of code to be added in the MainActivity.cs file:
AuthenticationAgentContinuationHelper.SetAuthenticationAgentContinuationEventArgs(requestCode, resultCode, data);
That line is used in
OnActivityResult to ensure that the control goes back to MSAL once the interactive portion of the authentication flow ended.
The MSAL main primitive,
PublicClientApplication, is initialized as a static variable in App.cs. At application startup, WelcomePage attempts to get a token without showing any UX - just in case a suitable token is already present in the cache from previous sessions. This is the code performing that logic:
protected override async void OnAppearing()
App.PCA.PlatformParameters = platformParameters;
// let's see if we have a user in our belly already
AuthenticationResult ar = await App.PCApplication.AcquireTokenSilentAsync(App.Scopes, "", App.Authority, App.SignUpSignInpolicy, false);
Note that this code is also used for assigning the previously mentioned MSAL's
PlatformParameters with the
platformParameters value, itself assigned by the platform specific PageRenderer as discussed. If the attempt to obtain a token silently fails, we do nothing and display the screen with the sign in/sign up button. If the attempt is successful, we navigate directly to TasksPage. When the sign in/sign up button is pressed, we execute the same logic - but using a method that shows interactive UX:
AuthenticationResult ar = await App.PCApplication.AcquireTokenAsync(App.Scopes, "", UiOptions.SelectAccount, string.Empty, null, App.Authority, App.SignUpSignInpolicy);
The TasksPage attempts a silent token acquisition directly at load time - and given that the app navigates ot this page only upon a successful sign in/up or token acquisition, normally the operation will succeed.
Following that, the page uses the token just obtained to secure a call to the web API, which results in a list of tasks. The task creation logic works similarly.
The sign out logic is very simple.
For more information on Azure B2C, see the Azure AD B2C documentation homepage.