Secure Multi Factor Authentication with Azure Sphere

The goal of this project is to use Azure Sphere hardware to add an extra level of security to what is already one of the best ways to secure a website.

Azure AD B2C

Microsoft Azure provides some great ways to implement authentication on your website - or anything else for that matter. Perhaps the coolest is the one with a mouthful of a name Azure AD (Active Directory) B2C (Business to Consumer).

Essentially Azure AD B2C means you can leave Azure to manage all your users and passwords for you. There's no need to write code for password reminders. There's no need to worry if your encryption is up to scratch. All the hard stuff is done for you.

It's also possible to extend Azure B2C - and that's what we'll be doing for this project. We'll add Azure functions, Azure IoT Hub, and Azure Sphere in to the mix to make sure that even if some does find your password on that Post-It note stuck to your monitor, they still won't be able to pretend to be you.

Multi Factor Authentication

Multi-Factor Authentication authentication means using more than just a password. It can take a few forms but often means requiring "something you have" (cell phone, fingerprint) in addition to "something you know" (password).

Azure does provide some Multi factor Authentication (MFA) out of the box so you might be wondering why we're not just using that. Well, Azure only permits a text message to be sent to a phone. We will be allowing anything to be used. Whilst I've picked one way to authenticate myself, the real strength of this project is the flexibility it provides. This is Multi Factor Authentication - but Multi Factor Authentication done your way.

Once we have an Azure Sphere device confirming your identity it not a huge leap to imagine extending this any way that suits you. I'm going to use the NFC tag I have implanted in my left hand, but this can be extend to work with anything you like. It could be just a simple button press. You could use your work ID, fingerprint, PIN code, facial recognition - anything.

Structure of the project

One of the great things about Azure is the myriad of features that are available to you. We'll be using quite a few of these so I'm going to describe the different layers that we'll be using.

Azure App Services - We need a website to demonstrate the process end-to-end, so we'll start with a simple website that asks you to login. This will be hosted using Azure App Services.

Azure AD B2C - This is Microsoft's way of securely managing users and passwords for you. It also allows you to integrate with social authentication (Hotmail, Google, Facebook, etc.). This is the base for our authentication.

Azure Functions - We need some code that Azure AD B2C can call in order to check whether you're really you. Sure, we could knock up another website can call an API there, but when all you need is a function, why worry about what's hosting it? Functions to the rescue.

Azure IoT Hub - There are a couple of way to communicate with your Azure Sphere device. Azure IoT Hub is the simplest. Whilst it's more commonly used to receive sensor information from an IoT device, we can also make calls to our Azure Sphere hardware and wait for a response. That's what we'll be doing here.

Azure Sphere - This is the focus of this project. This is the device that will be asked "is Fred really trying to login?" and (along with the Azure Function) it will give us a Yes or No.

So, those are the pieces of the puzzle. Put together they should give us additional confidence in the identity of the user logging in to our website. Let's look at them piece by piece.

Our website - Azure App Services

OpenID Connect is the protocol behind Azure AD B2C. It isn't just restricted to logging in to websites, but that's where it's most often used. I've created a demo website that's as simple as possible to demonstrate just the features we need. I started with Microsoft's standard new "ASP.NET Core Web Application" and configured it to use Azure AD B2C for authentication. This was my first commit in GitHib so you can easily see the changes made after this point.

Then I added a simple page to display the information in the Javascript Web Token (JWT) so we can see if everything worked as intended. In order to see the process in action all we need to do is click "Sign in" and login using Azure AD B2C. We then have 10 seconds to either provide our Multi-Factor Authentication (or not).

You will see the extra information that we've added highlighted below. azsphereConfirmed is the most important, as this tells us that the MFA worked. We use this to restrict access to an especially sensitive admin page. The other fields just show us what's going on. In this case I identified myself using an NFC tag with ID of 04(redacted)884. I've hidden this information as this is the ID on the tag that's permanently implanted in the back of my hand.

You'll find this application hosted at https://sphereb2cweb.azurewebsites.net/ if you feel like taking a look.

Our user store - Azure AD B2C

Azure AD B2C is Microsoft offering to do all the complicated and risky management of users and passwords for you. It's an impressive and extensive service that would swamp this project if I tried to teach you all about it right now. Luckily it's something that Microsoft have documented very well. B2C does have some 2 Factor Authentication built-in but that will only allow a code to be texted to a mobile phone for you to enter as you log in. In order for us to do something a little more custom, we need to delve into the murky world of the Identity Experience Framework and start editing XML configuration file.

Before doing that we need to add a couple of custom attributes for our users. We need the following:

• secondaryMethod This is the way we want to do our multi-factor authentication. The values supported in the sample project are nfc (and NFC tag) and button (a simple button press on the Avnet Azure Sphere Development Kit.
• expectedValue For nfc this should be the NFC tag ID (in hex, no spaces). For button it should be button_a or button_b.
• deviceName This is the device name assigned to the Azure Sphere device so it can be found in Azure IoT Hub.

Editing IEF configuration files isn't for the faint-hearted and once again I'd have to write way more than this project would allow to teach you all about them. This guide shows you how to add custom claims to the user registration process and I did this in order to allow a user to set these parameters when registering for the site of editing their profile.

Now we need to make use of these values as a user logs in. This guide shows you how to call a RestAPI during the log process. If you're interested in exactly what I did then take a look at the XML files under the Identity Experience Framework folder in github. You'll be able to see from either the comments or the git history what's been changed from the base files.

OK, so now we have Azure AD B2C calling a web API in order to get some more information. Now let's make sure that information comes from our Azure Sphere device!

Our logic - Azure Functions

Azure Functions are the "serverless" side of Azure. You define a function and leave making sure that it runs on some server(s) somewhere to someone else. You'll find the code for this in the SphereB2CFunction project part of the solution. This function expects some parameters passed in from our Azure AD B2C webhook - the device name to pass the request to, the method (nfc or button) we're using and the value to match (e.g. NFC tag ID). The core code of this function is as follows:

HubService is wrapping an Azure IoT Hub direct method call. You can see that we pass in the device name and the authentication method and simple check the return value. If it matches what we expected then confirmed is set to true. The debug output is just that - to help debugging and nothing more.

Connectivity - Azure IoT Hub

In order to communicate with your Azure Sphere device you will need to register it with Azure IoT Hub. This process involves adding your device to the IoT Hub and retrieving an automatically generated connection string to allow your device to call back to the Hub. (In this case it seems to be little more than a keep-alive signal.) If you're new to connecting your device to IoT Hub then i can recommend this tutorial.

IoT Hub seems to be most frequently used to collect telemetry data from a device, but there are also two ways we can do Cloud to Device communication. The first is a Cloud to Device message. This is pretty much one-way communication, so not really suited to what we need. We're going to use a Direct Method call. Before wiring things up to the Azure Function we can actually test the method manually in the Azure Portal.

Azure Sphere - Hardware

OK, finally we get down to the hardware. All you need is an Avnet Azure Sphere Starter Kit. You'll probably want to use the NFC authentication, so simply attach your NFC click module to the left hand mikroBUS connector marked "1". If you don't have an NFC module then we can still use a button press as our authentication mechanism.

An OLED display is nice to have, but also not essential. Here I'm using a Click OLED-B display which just plugs right in to the board. An earlier version used acheap OLED module that you'll find all over the web connected to the 4-pin OLED display connector on the board. If you have one of those then an earlier version of my code will work with that.

That's it! Now connect your device to your PC over USB and we can deploy some code. I'm going to assume that you've claimed your Azure Sphere device and attached it to your Azure tenant. This is essential for any Azure Sphere development and once again too large a subject to cover here. If you're new to Azure Sphere then I've written a review with a getting started guide over on Element14.

Azure Sphere - Software

Our Azure Sphere device is expected to respond to a direct method called Authenticate (with a secondaryMethod parameter of nfc or button) and respond with the appropriate value to match what we've stored in Azure B2C. You'll find the code for this in the SphereB2CDevice project in github solution.

The Azure Sphere device is required to poll Azure IoT Hub with a "keep alive" signal, and you can see the green LED flash to show that this is working.

When it receives a request for authentication, the blue LED lights and a message is displayed on the OLED display.

If the request is for a simple button-press confirmation it will wait a maximum of 10 seconds for a button to be pressed and confirm whether this was button_a or button_b.

If the request is for a NFC tag then it uses the PN7120-based NFC click board to read the ID of any NFC tag it can find. Once again, 10s is the timeout here to prevent our web application seeming too unresponsive.

Whilst I have used these two methods, obvious the fact that we have written our own custom Multi-Factor Authentication means that this confirmation can be anything you want!

Work RFID card? Sure!
A secondary PIN or password? Easy!
Fingerprint? If you have a fingerprint reader, no problem!
Compulsory MFA? Sure. I allow with and without, but we could insist on it.

Demonstration

The first demonstration is a new user signing up to our demo site and specifying that we want to use Multi-Factor Authentication via Azure Sphere.

Once we have our accounts configured, we can log in using MFA for extra security.

Conclusion

I hope you've enjoyed reading about this project, and finding out about various aspects on Microsoft Azure - not just Azure Sphere - along the way.

As I mentioned earlier, OpenID Connect authentication isn't just for websites. What you get back from Azure AD B2C is a cryptographically signed chunk of JSON which describes the user. It's time limited - normally to an hour. You can trust that it's not been tampered with as Azure has used a private key to sign that the message is valid, and it's easy to check this signature. This JSON Web Token (JWT) can be passed anywhere you want and is effectively a security pass saying "this is me". It can be sent with an API call to another service, or used to secure a mobile application. It's lightweight enough that even another Azure Sphere device could accept and validate it. Whenever you've seen "login with Google / Facebook", etc. it will have been OpenID Connect behind the scenes, and now you can add Azure Sphere hardware to the mix.

You really can Secure Everything. So, what would you secure?