You will see a lot of the same techniques as previous methods - just updated for todays topic. Let’s get started!
The bright side of todays topic is that, with a few twists, you can use this same code if your app targets enterprise users. There is a point in the configuration where you need to select “Anyone” and “Enterprise users only” - just make the right selection!
The Azure Active Directory side of things
Start by signing onto the Azure portal. The account is free, and doing the actual sign-up is like any other cloud provider. Once you have got into your account:
Open the Azure Active Directory blade:
Click All services in the left-hand menu.
Enter Active Directory in the search box
Click Azure Active Directory.
You can favorite any resource types you use on a regular basis to get easy access to them in the left-hand menu.
Click App registrations in the blade menu.
Click New registration.
Enter a name for this app. I used Tailwind Photos for Android.
Select the supported account types. I used Accounts in any organizational directory and personal Microsoft accounts (e.g. Skype, Xbox). This is where you can lock your authentication down to just enterpise users if needed.
Under Redirect URI, select **Public client (mobile & desktop), then enter a redirect URI that is unique to your app. I’m using tailwind-photos://auth. Pick your own redirect, though.
Click Register.
This will give you an Application (client) ID which you will need later.
The app side of things
As with the other libraries, we need to do a little bit of setup. Let’s start with the library. We previously added mavenCentral() as a repository, so we only need to add the library in the module level build.gradle file:
Next, we already have the INTERNET permission, but we also need the ACCESS_NETWORK_STATE permission in the AndroidManifest.xml file:
Also in the AndroidManifest.xml, we need to add a definition of the activity that the MSAL (Microsoft Authentication Library) uses:
The data values come from the redirect URI that you entered in the configuration. I entered tailwind-photos://auth, so that is where the scheme and host are derived from. Notice how this activity definition is similar to the Facebook definition!
We need to create an msal_config.json file that contains the configuration we have set up. Here is an example:
To create this:
Right-click on res, select New > Directory. Enter the name raw.
Right-click on the newly created res/raw directory, select New > File. Enter the name msal_config.json.
Copy the above JSON into the newly created file, replacing the client_id and redirect_uri values with your own.
Let’s get on with the code. As before, I’ve added calls into AuthenticatorActivity to call the abstracted authentication class:
This code should be familiar by now since we’ve done the same thing for each authentication implementation. Let’s take a look at the MicrosoftManager class:
This is all fairly standard boiler-plate code for MSAL. However, I’ve not completed the task. Specifically, I’ve left what happens in userInformationCallback(). When you press the Microsoft login button, it will go through the normal authentication mechanism, eventually calling userInformationCallback() with an authentication result. The authentication result only contains the access token. This is a JWT used for authentication purposes on back end services.
We need the name and email address as well. Fortunately, the information is contained within the JWT and JSON web tokens are not hard to decode. If you need to validate a JSON web token, then it is best to use a library. If you want to decode a JSON web token, they you just have to be aware that they are made up of two JSON sections that are base-64 encoded, plus a signature. You can replace the userInformationCallback() with the following code:
This will now construct the right AuthenticatedUser object without further network calls. You could, instead, do a Graph lookup to Microsoft Graph for the information. However, that’s an additional network call; mobile apps have enough to do!
Next Steps
You should be able to run the app at this point and authenticate with Microsoft authentication. If you stop and start the app again, pressing the Microsoft authentication button will silently authenticate you - there is no need for another prompt if the token is still valid.
In the next article, I’ll tackle Twitter authentication. Until then, the code is in GitHub.
I’m currently working on some automation within Azure to deploy a hub-spoke web application. This web application authenticates with Entra ID using an App Registration and Role-Based Access Controls (RBAS) using App Roles. So, I need to create an app registration, enterprise app, and create the app roles.
One of the persistent questions I get asked about Azure Mobile Apps is how to support older tables. Let’s say you have an older application that was never designed for mobile applications. It likely has a model like this:
If you are an Azure developer, you likely spin up an application, do some work, then shut it down again. However, shutting down resources and deleting them has an order to them. If your service is network isolated (in a virtual network), then you can’t delete the application until the private endpoints are shut down. Budgets don’t get deleted with the resource group. Diagnostic settings can’t be deleted if the resource no longer exists. There is an order you should do things:
I work a lot with Azure API Management, which means I turn up and down services quite a few times a day. Azure API Management has an awesome feature that prevents you from accidentally deleting a service, called soft-delete. Instead of immediately deleting the service, it marks it as soft deleted and purges it later on. Unfortunately, that means that you can’t immediately reuse that service name. In production, this is a great thing to have. In development, it turns into a pain. That’s b...
Leave a comment